Issue with Modification for Peristaltic Pump

[lmur...@vt.edu]

Hi All, 

I'm working to modify the FED3 to be used for operant liquid delivery. We've done this by switching the FED3 DC motor to a 5-6V Peristaltic Pump (Arduino Item #3910). We've got a working prototype, but found an issue in the software that I can't solve. I was hoping someone here may have more experience with pumps/motors and be able to help.

If an active nose poke initiates the dispense function (Fed3_Sip.Sipper, nearly identical to the FED3.Feed function) then making a second active nose poke or series of nose pokes quickly following it will cause the motor to turn at twice the speed/with twice the power, dispensing the wrong amount of liquid. A second poke during the dispense that's not done soon after the initializing poke will sometimes results in the motor pausing (as it runs the logpoke/logdata function, I assume) instead of the double dispense. 

Here's a link to a zip file with our modified code, including .cpp and .h files, two video files, and the data file for the videos. With the videos playing with volume up it's possible to hear the difference between normal dispenses ( _05 Dispense at Poke#2, Poke#3, Poke#6, _07 Dispense #1) and the super charged dispenses (_05 Dispense at Poke#4/5, Poke #7 into 8, _07 Dispense at Poke #9/10).

If anyone here has any knowledge, I'd really appreciate some help. I wouldn't be surprised if it's a simple change, like needing to change the underlying code for turning the motor to make it use max speed, or I'm just using the wrong kind of code to interact with the motor. 

Thanks for any info, 

Laura Murdaugh

[lmur...@vt.edu]

Couple of quick updates:

1) Added the Arduino file to the folder linked above. We're using a modified version of the ClassicFed3Menu system.

2) When one or multiple active or inactive pokes are made during dispense, one single poke gets added to the relevant poke count despite removal of the Left/RightCount ++ from code referring to Left/RightWithPellet, Left/RightDuringDispense, Left/RightinTimeout. If that poke would trigger pellet release (e.g., during FR1) then a second rotation/dispense is made. 

3) The double-speed does not occur when this code is used with the FED3's DC stepper motor, but the issue outlined in #2 still occurs. 

[Lex]

Hi Laura!  Super cool you're doing this!  How are you wiring the pump up to the FED3 BTW?  Are you using the motor header inside of FED3?  The FED3 code is configured to control a stepper motor and not a DC motor like what's in the peristaltic pump.  I'm not surprised you're getting strange behavior if you just connected a DC motor to the pin headers. 

So I think your options are to:

1) Keep hardware hacking!  Try connecting the motor to different pins, make sure one of them is connected to ground (the outer-most pin on the header), perhaps connected to multiple stepper pins, see if anything works the way you want it to.

2) Keep code hacking!  It sounds like you have it working fine with one poke, it's just multiple pokes while dispensing that mess it up.  If you simplify the void FED3_Sip::Feed function to stop monitoring for additional pokes it might work for you.  So the logic is change this function to move the pump as much as you need to, without allowing for additional poke reads in that function.  You can also put a delay(2000); or something at the end to just make sure the motor finishes before another poke is allowed to be detected.

3) (most correct method and also the most work) Remove the stepper control code in the FED3 library and configure the TB6612 motor driver chip inside FED3 to control your pump instead of the stepper.  The TB6612 chip is capable of controlling a DC motor but it will require a re-write of how FED3 handles the motor to make this work correctly.  See here for examples.  If you do this you can get experience with how the chip works by buying that break-out board and using it to follow the examples on the Sparkfun page, and once you understand it you can wire the chip inside of FED3 up to the pump.

Your other issue is easier :)  The poke delaying the motor are expected - whenever a poke is made the system waits until the poke is clear so it can time how long the poke is.  Mouse pokes are typically <200ms so it's not super noticeable but that's happening all the time. To stop that behavior you can comment out these lines in the log poke functions:

while (digitalRead (RIGHT_POKE) == LOW) {} //Hang here until poke is clear

while (digitalRead (LEFT_POKE) == LOW) {}  //Hang here until poke is clear

You'll just lose the ability to have an accurate PokeTime column, but it sounds like you might not care about that and doing this this might solve your other issue.

Good luck! -Lex

--
You received this message because you are subscribed to the Google Groups "FEDforum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedforum+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fedforum/6eaef534-ff8a-49d7-adfc-7ab9242c8b50n%40googlegroups.com.

[lmur...@vt.edu]

The weirdest thing is that issue #2 still occurred when I removed the logic in FED3_Sip.RotateDisk for poke checking. FED3_Sip.Feed isn't ever called, and the replacement function FED3_Sip.Sipper doesn't have any poke check logic built into it. But, by removing that logic and combining it with a Timeout(10) at the end of RotateDisk I've been able to bypass the super speed and extra poke issues, which will be good enough for us to do a short test with mice to see if we can capture when they put their noses into the magazine to drink water.

This leads me to think that there may have been some flaw in the order of operations or coding of Sipper, RotateDisk, or PelletAvailable. That somehow the first or final poke wasn't getting logged until after the pelletavailable had been changed to false, allowing for it to be coded as a regular poke, maybe. That'll be fun to dig into.

Either way, thanks for the help! I'll get started on trying to get the motor working using some of the code available on the sparkfun page. I'd hate to accidentally burn out our motors prematurely by engaging with them incorrectly. We have tons of the adafruit breakout TB6612FNG boards because all of our FED3s are the v5.1/5.2 ones, which we make in-house. Am I correct in assuming that these two boards are similar, and that they just have different pin placement, so I'd have to be sure to double check and change any pin numbers or definitions by comparing the schematics for the two boards? 

[Lex]

Oh right... to get the pokes to stop doing that it will require a bit more digging into the code.  The pokes are configured to launch "interrupt" functions when activated, this allows the pokes to be detected when other things are going on, most importantly so it can wake up while it is sleeping.  It would be possible to deactivate the interrupts (and sleep) but that will have implications throughout the codebase.   

So if you can get something usable for testing I would ignore this issue for now, and when you get to the point where it's critical to turn the interrupts off I can point you in the right direction and we can see what happens!

To view this discussion on the web visit https://groups.google.com/d/msgid/fedforum/26f9e7ad-d208-476a-9e53-70e1cbc8d995n%40googlegroups.com.