View Full Version : Photosensor as encoder for bang bang.
Hello folks,
Helping my programmer do a bit of research. How would we go about pulling the period of time between rotations of a flywheel using a photosensor and tape to use with a bang bang in Labview.
Mark McLeod
08-02-2013, 10:32
Here's one way to do a tach with a photosensor:
http://team358.org/files/programming/ControlSystem2009-/LabVIEW/Tachometer.jpg
what is and where do i find the 'Dig Scr' thingy between the DIO open and the COUNTER open
Mark McLeod
08-02-2013, 18:28
It's in
WPI Robotics Library -> I/O -> DigitalInput
Here's one way to do a tach with a photosensor:
http://team358.org/files/programming/ControlSystem2009-/LabVIEW/Tachometer.jpg
Mark,
Is the Counter/ConfigTimer (blue arrow) where the FGPA sampling size is configured?
If so, does the "5" (green arrow) mean FPGA sample average is set to 5?
Does Counter/Get (red arrow) return the same thing as the GetPeriod() method in the Counter class in C++ and Java (i.e. period, in seconds, of the tooth count, based on the last 5 samples) ?
Thanks.
Mark McLeod
08-02-2013, 21:40
In a word, Yes.
The 5 there is just an example for # samples to average.
(For the OP's programmers, e.g., Bunniy) For example, if you have multiple pieces of reflective tape around the wheel to increase your resolution, then averaging removes any displacement errors in positioning the individual pieces of tape. You know, if the pieces of tape aren't perfectly spaced, perfectly sized, perfectly oriented. If you just use 1 piece of tape then I'd probably take the LabVIEW default of 1.
That Get wire is the average Period (in seconds) between pulses.
In a word, Yes.
The 5 there is just an example for # samples to average.
For example, if you have multiple pieces of reflective tape around the wheel to increase your resolution, then averaging removes any displacement errors in positioning the individual pieces of tape. If you just use 1 piece of tape then I'd probably take the LabVIEW default of 1.
That Get wire is the average Period (in seconds) between pulses.
Thank you.
I have a more general LabVIEW question if I may. Before I posted the above question, I tried for about half an hour to find the answer on the internet. Do you (or does anyone reading) know of a site where you could type, say, "Counter Config Timer" into a search box and it would display the LabVIEW help screen for that icon? I had no success with Google.
Thank you mark for telling me that it should be set to 1. No wonder my wheel was spinning so fast!
im still having trouble. my motor keeps spinning as fast as possible even when i set the rpm to even 200.
Mark McLeod
08-02-2013, 22:15
Show a snippet of the code you're using.
I may be a little slow responding, I'm shoveling snow.
P.S.
If you don't know what a number in the example means, ask.
You don't want the 99 for example, because you only have 1 tick per revolution.
Greg McKaskle
08-02-2013, 22:21
Ether, I don't know of a site that does that, but the editor will. If you click on search in the palettes, type Counter Config, it will have only one item in the list. Hover and the Context help window will show that item's help. There is also a function called QuickDrop that some folks just love. You hit Ctl-Space and type some of the name and it does the same sort of list and you click and drop the node. It doesn't look like the help updates until you drop the node.
Greg McKaskle
and this is the rest of it. The first picture us what is in the periodic task vi
Mark McLeod
08-02-2013, 23:53
So you're taking the total revs since the last time you checked the counter.
Dividing by a time constant, filtering the result, and applying a slew rate limiter?
I'm not a fan of the Counter reset applied that way. There's a window to drop counts.
Seems a bit much for flywheel.
Is the slew rate limiter to avoid extended stall time at full power for the flywheel?
P.S. I overlooked that the slew rate is probably bypassed with the False Case.
Is that really 360 counts per revolution?
I thought you only had 1?
I don't think you want that 60 or 360 applied there, but maybe I haven't grasped what you are calculating.
Alan Anderson
09-02-2013, 00:03
and this is the rest of it.
Are you trying to read buttons and set a global variable in Begin.vi? It only runs once when the program starts up, and usually isn't an appropriate place to do I/O actions.
billbo911
09-02-2013, 00:04
here
Bunniy,
The first thing I would check is if you are actually getting an RPM reading by placing a "probe" just before the ">= " comparitor. Also, make sure the other input to the comparitor is seeing the desired RPM value.
If you are not seeing either at that point, then you will know where to start digging further.
here
I would recommend you let the FPGA compute the period in hardware with its 153KHz sampling and 1MHz clock (like Mark showed), instead of doing it in software. There's no need for the IIR filter if you set the proper size for the FPGA's sample ring buffer. If you you need to avoid large current spikes at startup (perhaps to prevent Jags from cutting out), try speed-based throttle limiting instead of time-based slew rate. I would avoid using a Jag for bang-bang because of the startup current spike.
billbo911
09-02-2013, 00:50
So you're taking the total revs since the last time you checked the counter.
Dividing by a time constant, filtering the result, and applying a slew rate limiter?
I'm not a fan of the Counter reset applied that way. There's a window to drop counts.
Seems a bit much for flywheel.
Is the slew rate limiter to avoid extended stall time at full power for the flywheel?
P.S. I overlooked that the slew rate is probably bypassed with the False Case.
Is that really 360 counts per revolution?
I thought you only had 1?
I don't think you want that 60 or 360 applied there, but maybe I haven't grasped what you are calculating.
When I first saw the code I was surprised at how familiar it looked, then I realized, I posted it last year.
Mark, would replacing the "Reset Counter" with a feedback loop and subtracting the previous count from the current count be a more stable option?
Both the IIR filter and the slew rate limiter were placed in this code as ways to compensate for other issues.
The slew rate limiter really is only needed when using a Jaguar. The current limiting circuit in the Jag can trip if the start up current is too high. If using a Talon or Victor, this entire block of code can be bypassed or completely removed.
Honestly, the IIR filter shouldn't be used. It introduces lag into the control. I put it in there as a way to smooth out the RPM signal. I believe the main reason the signal was noisy was due to the use of a "wait" loop instead of a timed loop in the original version. In addition, we were using "Get Rate" in the original version. "Get Rate" is an instantaneous measurement that is inherently noisy. This version uses a count divided by time to determine RPM, which is a much cleaner approach. This filter can be bypassed by setting the filter strength to "0", or just deleting that section of code.
The "360" is the number of ticks per revolution of the encoder it was designed to be used with. If the encoder is just a couple of lines on a wheel and an optical sensor, the this value needs to reflect the number of lines.
Bang-Bang is a simple control system. A comparison of the current RPM to the desired RPM. If the current is at or above the desired value, then turn off the motor. If it is below, turn the motor on at full power. Anything else in the loop just clutters the process.
my buttons are in teleop and send the numeric values to the global variable which is then sent to the bang bang controller in the periodic tasks.I downloaded the bang bang and did not change it except for the global variable. Now i dont know what most of the numbers mean but tell me what you think i shouild change.
P.S. sorry for my little kid posts and all, i just got my license yesterday, and a flat the same day, lost and found our pneumatic wheel at homedepot, and had a long day of course :P
billbo911
09-02-2013, 10:23
my buttons are in teleop and send the numeric values to the global variable which is then sent to the bang bang controller in the periodic tasks.I downloaded the bang bang and did not change it except for the global variable. Now i dont know what most of the numbers mean but tell me what you think i shouild change.
P.S. sorry for my little kid posts and all, i just got my license yesterday, and a flat the same day, lost and found our pneumatic wheel at homedepot, and had a long day of course :P
Start by replacing the "360" in the left side of the periodic tasks with the number of counts you will have from a single rotation of the wheel.
Make sure the filter level is set to "0", and lastly that the Boolean for the slew rate filter is set to "False".
Does your Begine.vi have the correct configurations for the counter? (That was also included in the .zip version of the Bang-Bang control. The separate versions of the Bang_Bang I uploaded just added extra features.) If it is not there, then you will not be getting any input to the control and it will always be full on.
Mark McLeod
09-02-2013, 11:05
Mark, would replacing the "Reset Counter" with a feedback loop and subtracting the previous count from the current count be a more stable option?
A feedback node and subtraction would preserve the integrity of the counter.
You do have to be aware of how high the Counter can count and provide for wraparound if resolution makes that a potential problem.
Counter Reset can be used when the shooter is turned off or first turned on, i.e., before or after the count integrity matters.
Also, it should be made clear that a crude filter and a loss of resolution is being applied by converting the Counter to RPMs before doing the tests.
My preference is to do all processing and comparisons in native units and only convert to RPMs for the human display.
Bunniy, your Counter initialization in Begin.vi looks fine.
See, you get your license and immediately you're doing errands.:)
The OP didn't mention the shooter speed(s) or the execution rate.
So I'll pick some numbers.
At 4500 rpm true wheel speed, sampling the counts of a one-per-rev sensor at a 20ms rate will give you 1 count 50% of the time and 2 counts 50% of the time. So if you compute speed by dividing counts by elapsed time, your measured rpm will be 3000 half the time and 6000 the other half, and that's assuming perfect 20ms scheduling of your control algorithm.
That's a lot of noise.
I wonder if the shooter inertia would be large enough to allow bang-bang to work with a signal like that. Maybe some inquisitive team will try it and report their results.
If it doesn't work, let the FPGA do the sampling (at 153KHz) and timing (with its 1MHz timer). You'll see +/-3 rpm, and your 20ms scheduling doesn't need to be tightly held.
Thank you. That seems to have helped. Also i am using a pneumatic wheel and a painted a small white line of paint about 1/3 of an inch in diameter. Should i make it bigger. I am looking at my rpm calculator and it was only showing me 30 at full power. My thought is that it is not registering fast enough. Any suggestions?
where exactly is the FPGA and what does that mean
where exactly is the FPGA and what does that mean
If you use the LabVIEW code that Mark McLeod posted earlier (http://www.chiefdelphi.com/forums/showpost.php?p=1229855&postcount=2) it will use the FPGA.
FPGA stands for Field Programmable Gate Array. You can Google it for all the hairy details if you like.
In a nutshell, it's a programmable piece of hardware that is in the cRIO (separate from the CPU that is running your program). The FPGA processes all the digital signals coming into the DSC. It polls those signals at 153KHz and has a 1MHz timer to timestamp events (like ticks from a sensor). The FPGA makes its information available to your program running in the cRIO CPU. It relieves the CPU from having to do the high-speed polling.
Mark McLeod
09-02-2013, 15:45
Ether means get the Period the way I showed how earlier.
That comes from the FPGA which is the chip that processes all the inputs and outputs on the cRIO.
FPGA stands for Field Programmable Gate Array.
P.S.
Boy am I slow today.
But I did just finish moving 1500 cubic feet of snow, shovel-full by shovel-full.
I still have no luck. Here are is my current project. I have the rpm value sent to my driver station which is named "Cim". Like i said i just have an photosensor and a little piece of the wheel white. It always runs at full speed when i press different desired RPM values. I dont know if it is a problem with the begin or even my global variable. Please look over it for me
billbo911
10-02-2013, 12:38
Mark,
I created a "Count only" version of the Bang-Bang control. Does this look correct? If so, I'll add it to my "White Paper" options (http://www.chiefdelphi.com/media/papers/2665).
The only modifications needed are to replace the counter and motor names with the actual names.
If actual RPM is needed, that can be added here or elsewhere.
I also put a version together that uses the period approach you described earlier.
so i have tried to use it and i pluged in the Photosensor to the FPGA which is the card on the Crio. Now in the begin do i have to set it up a certain way or something? Because i tried using the robot with your new code and it is not even spinning the motor now
i pluged in the Photosensor to the FPGA which is the card on the Crio
?? The sensor should be wired to a DIO on the DSC.
And can you also check my global variable
The DSC is?
It's the blue thingy where you wire all your DIO.
Haha is it the digital side cart i should wire the Photosensor to or the blue thingy on the crio
Haha is it the digital side cart i should wire the Photosensor to or the blue thingy on the crio
That's why we avoid using words like "thingy" in this forum.
You want to wire your sensor to a DIO on the Digital Side Car.
haha thank you. I will try it.
Mark McLeod
11-02-2013, 14:13
Just a caveat about the Photosensor.
What model are you using?
If it's this Kit one:
http://team358.org/files/programming/ControlSystem2009-/sm_PhotoSensor.jpg
Then the power wiring gets a bit unusual.
The signal connects to the Digital Sidecar, but it can be unwise to take power for this particular sensor from there.
It doesn't handle voltage dips well.
We can describe what to do, but I don't want to clutter the thread if you're using some other model.
P.S.
I'll take a look at your revision Bill. I just have had only snippets of time over the past couple of days.
I know a lot of new names for snow now, but not in polite company...
Yes i am using that kind. I have it powered by the power distribution board
I used what you gave me and now my motor wont even spin at all
I used what you gave me and now my motor wont even spin at all
He appears to be talking to you, Mr Bill. His post is linked here:
http://www.chiefdelphi.com/forums/showpost.php?p=1230976&postcount=22
I fixed the spinning part. I wired it wrong. But still the motor is still spinning as fast as possible
It is still making my motor spin as fast as possible
Mark McLeod
11-02-2013, 15:10
Yes i am using that kind. I have it powered by the power distribution board
The problem with this particular sensor is that it's minimum voltage spec. is 10.8v.
With a fresh battery and early in a match without pushing contests and not a lot of motors powered all at once, that's probably fine.
The danger is when the robot battery voltage drops below 10.8v (because it's towards the end of a match full of pushing defensive robots or the battery gives out early) the feedback from the sensor can become random. It won 't count correctly.
There is an alternate source of guaranteed stable power if you are using a 24v Solenoid Breakout. The sensor can be wired just to an available power pin.
can you show or tell me where or what that is that i have to wire it to
Mark McLeod
11-02-2013, 15:31
For now I'd leave it where it is until you get the code figured out and working correctly.
Are you using solenoids this year?
If you are, then are you using 24v solenoid came in the Kit the past couple of years. This year they were offered in FIRST Choice.
i have it hooked up and i had just hooked it up to the solenoid breakout card. but not there is no power to the photosensor
NOw i got it to work at 24 volts. Now i need the code to work
I am getting a reeding now of Rpms between 500 to about 3000. But still my motor keeps going very fast
I am getting a reeding now of Rpms between 500 to about 3000. But still my motor keeps going very fast
Post a PNG screenshot of your speed controller code.
With a 20ms execution rate using counts to read a one-per-rev sensor on a wheel spinning at 2000 rpm, you're going to see a *lot* of noise.
The value (10) you put underneath the indicator, what does that number mean exactly.
The value (10) you put underneath the indicator, what does that number mean exactly.
@ Mr Bill: He's talking to you again (http://www.chiefdelphi.com/forums/showpost.php?p=1230976&postcount=21).
@ Bunniy: Many folks don't use the threaded display and can't tell who you are talking to if you just use the pronoun "you".
here
I don't think the "counts" method is going to work with a one-per-rev sensor. I think you need to use the "period" method that Mark posted.
@ Ether: Thank you, im new to chief delphi so i dont know this
@ Ether: Thank you, im new to chief delphi so i dont know this
We all started out new and had to learn. Try clicking the "quote" icon instead of "quick reply" and it will quote the message to which you are replying.
That will provide sufficient context.
We all started out new. Try clicking the "quote" icon instead of "quick reply" and it will quote the message to which you are replying.
That will provide sufficient context.
thank you
Mark,
I created a "Count only" version of the Bang-Bang control. Does this look correct? If so, I'll add it to my "White Paper" options (http://www.chiefdelphi.com/media/papers/2665).
The only modifications needed are to replace the counter and motor names with the actual names.
If actual RPM is needed, that can be added here or elsewhere.
I also put a version together that uses the period approach you described earlier.
the period one is not speeding my motor
I don't think the "counts" method is going to work with a one-per-rev sensor. I think you need to use the "period" method that Mark posted.
Why would using the period method be better?
A feedback node and subtraction would preserve the integrity of the counter.
You do have to be aware of how high the Counter can count and provide for wraparound if resolution makes that a potential problem.
Counter Reset can be used when the shooter is turned off or first turned on, i.e., before or after the count integrity matters.
Also, it should be made clear that a crude filter and a loss of resolution is being applied by converting the Counter to RPMs before doing the tests.
My preference is to do all processing and comparisons in native units and only convert to RPMs for the human display.
Bunniy, your Counter initialization in Begin.vi looks fine.
See, you get your license and immediately you're doing errands.:)
I have literally tried so many times to just get my wheel to my desired rpm. Can you show me or help me in anyway to get it to work with my photosensor
Why would using the period method be better?
To understand why, you have to do the math.
Using the "period" method, like Mark posted earlier in this thread, the FPGA samples the sensor at 153KHz and records the elapsed time between pulses with a 1MHz clock. For a one-per-rev sensor (like yours) on a wheel spinning at, say, 2000 rpm, that gives you a very accurate and hi resolution signal. See attachment.
The "count" method is very accurate for high speeds with high counts-per-rev sensors like a 360CPR encoder. But for a one-per-rev sensor like yours, it's not very good. At a wheel speed of 2000 rpm and sampling every 20ms, you don't get enough counts to accurately determine what the speed is. Sometimes you'll get 1 count, and sometimes you'll get *no* counts. You can't convert that into a useable speed signal.
See attachment.
To understand why, you have to do the math.
Using the "period" method, like Mark posted earlier in this thread, the FPGA samples the sensor at 153KHz and records the elapsed time between pulses with a 1MHz clock. For a one-per-rev sensor (like yours) on a wheel spinning at, say, 2000 rpm, that gives you a very accurate and hi resolution signal. See attachment.
The "count" method is very accurate for high speeds with high counts-per-rev sensors like a 360CP encoder. But for a one-per-rev sensor like yours, it's not very good. At a wheel speed of 2000 rpm and sampling every 20ms, you don't get enough counts to accurately determine what the speed is. Sometimes you'll get 1 count, and sometimes you'll get *no* counts. You can't convert that into a useable speed signal.
See attachment.
Do you have a good method to use the period method with desired rpm
Do you have a good method to use the period method with desired rpm
I would recommend the method suggested in posts 17, 25, 26, 53, 58, and 60. Hopefully Mark can help you with the details. I am not a LabVIEW guru.
The only thing I'd change in what Mark posted is to set the FPGA samples to "1" instead of "5" for a one-per-rev sensor.
I would recommend the method suggested in posts 17, 25, 26, 53, 58, and 60. Hopefully Mark can help you with the details. I am not a LabVIEW guru.
The only thing I'd change in what Mark posted is to set the FPGA samples to "1" instead of "5" for a one-per-rev sensor.
Its just that i have tried multiple times and i really want someone to tell me how the entire periodic task and begin should look. Considering im using a photosensor and only one tick per rev. Because i just want to get my wheel to be at a certain rpm with a push of a button and i have been trying to do this for 5 days now and no luck.
Hi everyone,
I just wanted to say thank you for all of the help that you all have been giving our programmer. He is working solo on this and is learning much of it without local support. We are slowly making progress and appreciate all of your efforts.
When I first saw the code I was surprised at how familiar it looked, then I realized, I posted it last year.
Mark, would replacing the "Reset Counter" with a feedback loop and subtracting the previous count from the current count be a more stable option?
Both the IIR filter and the slew rate limiter were placed in this code as ways to compensate for other issues.
The slew rate limiter really is only needed when using a Jaguar. The current limiting circuit in the Jag can trip if the start up current is too high. If using a Talon or Victor, this entire block of code can be bypassed or completely removed.
Honestly, the IIR filter shouldn't be used. It introduces lag into the control. I put it in there as a way to smooth out the RPM signal. I believe the main reason the signal was noisy was due to the use of a "wait" loop instead of a timed loop in the original version. In addition, we were using "Get Rate" in the original version. "Get Rate" is an instantaneous measurement that is inherently noisy. This version uses a count divided by time to determine RPM, which is a much cleaner approach. This filter can be bypassed by setting the filter strength to "0", or just deleting that section of code.
The "360" is the number of ticks per revolution of the encoder it was designed to be used with. If the encoder is just a couple of lines on a wheel and an optical sensor, the this value needs to reflect the number of lines.
Bang-Bang is a simple control system. A comparison of the current RPM to the desired RPM. If the current is at or above the desired value, then turn off the motor. If it is below, turn the motor on at full power. Anything else in the loop just clutters the process.
Question can you tell me or show me a code which uses a photosensor with a bang bang when it only has one tick per revolution
billbo911
12-02-2013, 01:43
Question can you tell me or show me a code which uses a photosensor with a bang bang when it only has one tick per revolution
I'll do my best. Sorry to have been away all day, it's build season and I was mentoring two teams today. Barely had time for lunch and got home an hour ago.
OK, 1 tick per revolution is REALLY LOW, so expect it to yield less than optimal results, though not unmanageable.
I searched the thread, but couldn't find any mention of the motor you are using, nor the wheel type. So, I'm going to make an assumption here that it will be a CIM driven direct drive shooter.
Let's assume you are getting a maximum of 5000 RPM. That means 83.3 RPS. If you gather a count sample 10 times a second, you will only see a maximum of 8.33 counts. So, 8, or 9. Miss just one count and your error is +- 625 RPM.
Therefore, you can only adjust your RPM in 625 RPM steps as well. That is not very much control.
So, that tells us using the period approach should be quite a bit better. With only 1 cycle per revolution, you don't need to worry about inaccuracies in the pulse positioning caused in manufacturing.
So, looking at the example Mark gave in post #2 (http://www.chiefdelphi.com/forums/showpost.php?p=1229855&postcount=2), the "Begin.vi" sets up the timer to average 5 counts. With the "Period" example I gave previously, it reads the samples every 20+ ms. If you use his "Begin.vi" and my Period.vi in your periodic tasks, you would only need to set the average to 2 counts. (Ether pointed out in a PM, there is no need to average with a single count encoder, so leave it at the default of 1.) Now when you feed a value into the control, it needs to be in the form of the period desired.
For example:
3000 RPM = (3000/60) = 50 RPS, therefore the period desired is 1/50 or .02 seconds.
Below is a picture of the "Period" control.
I do have the mini cim attached directly to the wheel. I am using a wheel like this http://www.andymark.com/product-p/am-0970.htm
Now i was able to make a small part of the wheel white so the photosensor has something to recognize. My question is how big should the mark actually be on the wheel for the photosensor to recognize it in a well fashioned time?
I do have the mini cim attached directly to the wheel. I am using a wheel like this http://www.andymark.com/product-p/am-0970.htm
Now i was able to make a small part of the wheel white so the photosensor has something to recognize. My question is how big should the mark actually be on the wheel for the photosensor to recognize it in a well fashioned time?
Please post a picture of the wheel showing the white mark. The shape and sharpness of the mark is important.
I'll do my best. Sorry to have been away all day, it's build season and I was mentoring two teams today. Barely had time for lunch and got home an hour ago.
OK, 1 tick per revolution is REALLY LOW, so expect it to yield less than optimal results, though not unmanageable.
I searched the thread, but couldn't find any mention of the motor you are using, nor the wheel type. So, I'm going to make an assumption here that it will be a CIM driven direct drive shooter.
Let's assume you are getting a maximum of 5000 RPM. That means 83.3 RPS. If you gather a count sample 10 times a second, you will only see a maximum of 8.33 counts. So, 8, or 9. Miss just one count and your error is +- 625 RPM.
Therefore, you can only adjust your RPM in 625 RPM steps as well. That is not very much control.
So, that tells us using the period approach should be quite a bit better. With only 1 cycle per revolution, you don't need to worry about inaccuracies in the pulse positioning caused in manufacturing.
So, looking at the example Mark gave in post #2, the "Begin.vi" sets up the timer to average 5 counts. With the "Period" example I gave previously, it reads the samples every 20+ ms. If you use his "Begin.vi" and my Period.vi in your periodic tasks, you would only need to set the average to 2 counts. (Ether pointed out in a PM, there is no need to average with a single count encoder, so leave it at the default of 1.) Now when you feed a value into the control, it needs to be in the form of the period desired.
For example:
3000 RPM = (3000/60) = 50 RPS, therefore the period desired is 1/50 or .02 seconds.
I am having trouble. I am using what you told me but my motor is not getting any value except for 0
Please post a picture of the wheel showing the white mark. The shape and sharpness of the mark is important.
Here is what it mainly looks like but with tape. i cant get the angle wuth the way our shootter is
I am using what you told me
Did you read the post very carefully? Specifically, did you follow these instructions:
So, looking at the example Mark gave in post #2, the "Begin.vi" sets up the timer to average 5 counts. With the "Period" example I gave previously, it reads the samples every 20+ ms. If you use his "Begin.vi" and my Period.vi
Did you read the post very carefully? Specifically, did you follow these instructions:
yes so i should set the number of samples to average as 1 with a 1 tick per revolution
OMG i finally got it. The encoder reset was my problem. Everything works Perfectly. Thank you everyone
Nothing better than watching a student finally 'getting it'. Thanks, Ether, Billbo, and anyone else for their help.
Gotta love CD.
billbo911
13-02-2013, 00:17
Nothing better than watching a student finally 'getting it'....
That is EXACTLY why I do what I do. Seeing that spark when it finally clicks, makes everything worth it.
So, is there a chance you can post the final version of the code you are using? Both Begin.vi and the control loop?
xraymypanda
14-02-2013, 20:15
If you are, then are you using 24v solenoid came in the Kit the past couple of years. This year they were offered in FIRST Choice.
Is this legal? My team has been looking for a high voltage power for a banner sensor and would like to do this but I can't find anything in the rules that says whether or not this is legal.
Mark McLeod
14-02-2013, 21:28
To be sure you should ask Q & A.
Past permissions are not present rules.
I don't see any restriction other than R70
Outputs from each Solenoid Breakout shall not cumulatively exceed 16W for the cRIO-FRC (8-slot) and 21W for the cRIO-FRC II (4-slot).
And solenoid valves alone don't draw that kind of power. I think that's addressing having the power draw of other custom circuits/sensors that might be connected there.
R66 is a weird one. It says we can't pump 12v into the Breakouts except through the Wago power ports. I wonder who tried to do what?
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.