Homemade bandsaw sawmill arduino controlled lift

We know that vibration triggers the interrupt in the reverse direction to real movement, and overall the effect should be self correcting, but I think that at some of the boundaries and decision points the retriggering of a match is causing some of the anomalies in the printouts.

Basically you recommend reducing the duty cycle of the motor to run the winch slower from the very start of the move? And slow even more at the end to prevent over run?

Yes, I am seeing overrun in the data. Slower movement will help and whether or not it is used overall, or just in a finish routine, which may start a 1/4 or 1/2 the move instead of at 7/8.

One thing that I thought of which could be causing the difference between the serial print of the encoder counts and the actual move is is there is something variable with the cable wrap. Previously you worked hard to keep it on one level and laid cleanly. The cable wrap on the drum is certainly an area which can lead to variation between the move and the count.

I am using the wheeled encoder that runs up and down the rail of the head. I wouldn’t think that the cable wrap should effect it any more. When I was using the gear tooth sensor, and stopping based on a certain number of teeth that passed the sensor, I could see where the cable would make a difference. However, I think that should be eliminated now that I am using the wheeled encoder.

Thanks!

Ok, here are the results with the latest code you provided: Again, the video and the serial should match up with one another. The results are still very sporadic. You can tell from the very first move. It moves less than 1/8th, but shows that there was over run on the serial.... This should mean that it was going farther than the 1/4" intended. I am not sure what is going on. All of this is being done with the engine off which I was able to get great results with before. There really shouldn't be much vibration at all.

Serial:
start...
start...
Trigger Up
softStartUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
Target = 80
Plus over run = 81
Target = 81
Plus over run = 81
Trigger Up
softStartUp
softFinishUp
softFinishUp
Target = 79
Plus over run = 84
Target = 84
Plus over run = 84
Trigger Up
softStartUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
Target = 80
Plus over run = 83
Target = 83
Plus over run = 83
Trigger Up
softStartUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
softFinishUp
Target = 82
Plus over run = 82
Target = 82
Plus over run = 82
Trigger Down
softStartDown
softFinishDown
softFinishDown
Target = -80
Plus over run = -90
Target = -90
Plus over run = -90
Trigger Down
softStartDown
softFinishDown
softFinishDown
softFinishDown
softFinishDown
Target = -80
Plus over run = -90
Target = -90
Plus over run = -90
Trigger Down
softStartDown
softFinishDown
softFinishDown
softFinishDown
Target = -80
Plus over run = -88
Target = -88
Plus over run = -88
Trigger Down
softStartDown
softFinishDown
softFinishDown
Target = -80
Plus over run = -88
Target = -88
Plus over run = -88
Trigger Down
softStartDown
softFinishDown
Target = -80
Plus over run = -91
Target = -91
Plus over run = -91

Video:

Yes, you are correct.

I am puzzled by the short moves (moves not consistent with serial counts) and was searching for explanations.

I do think that the short moves you are seeing can be caused by many extra interrupts due to noise of some kind. It may not be due to vibration from the saw motor since these tests are with the motor off, but there may be vibration, electrical or emi noise from the winch motor and the driver.

Besides the short moves with correct counts, I think that the multiple printing of "softFinishxx" and the double printing of
Target =xx and Plus over run =xx at the end of each report can be best explained by multiple noise induced interrupts.

In my thinking that the only way in which this block can repeat as indicated by the print out is if the count is going + and - across the conditional value due to noise or vibration caused interrupts.

if (count == targetCount - targetCount / 8) //1/8th of count to go
  {
    softFinish(); //comment out until pwm controller is implemented
  }

First, can you place strong external pullups on the A and B lines so that they have 2.2K to 5v. You could also try 1K.

How are the wires running from the encoder to the Arduino shielded? Are you using a shielded twisted pair?

One way to test this electronic noise/unwanted triggers theory is to try and raise the platform without the winch running. Can you manually turn the winch drum? It would be nice to confirm that just the encoder and the code with nothing else running gives the 80 counts for 1/4 inch.

One other question. If you don't call the softFinish() from the isr like it was originally commented out, do you still see moves not consistent with the counts. The way softFinish() is written, it is not great to be called from the isr, and it may be better to just set analogWrite() to the slowest value where the motor runs at the conditional point.

if (count == targetCount - targetCount / 8) //1/8th of count to go
  {
    //softFinish(); //comment out until pwm controller is implemented
 if (directionSignal == '+')
  {
    //Serial.println("softFinishUp");
      analogWrite(R_PWM, 127);
  }
  else //was set for a Down move
  {
    //Serial.println("softFinishDown");
      analogWrite(L_PWM, 127);
  }
  }

I had a feeling you were going to say noise.... that’s what I thought so I moved the motor driver back to the box where the buttons and arduino are located. I had intentions of mounting the motor driver nearer the winch motor and the output of the generator of the motor..... but I wanted to see if the location was causing the problems..... but.... as usual I ran in to other problems.

Now with it hooked up the head moves down as soon as power is connected... I did some testing, and I think I have lost the function of the pwm on the arduino. If I connect pin 5 on arduino to the motor drivers LPWM the winch goes down as soon as power is connected to the arduino and motor driver. If I connect pin 5 of the arduino to the RPWM pin of the motor driver the winch goes up as soon as I turn the power on.
I have reset the arduino and tried multiple codes and they all do the same thing. I also tried using pin 11 (I think it was 11, it was one that was labeled as a PWM) instead of 5 and changing it in the code but same result.

Pin 6 seems to work as it should. I don’t know if maybe the arduino has lost function and the odd (pwm)pins are connected some how?? And even pins are still functioning? Or, if the motor driver has gone bad.

There is also the possibility I have something connected wrong, but I have checked multiple times and don’t see anything.

The only thing I know to do is swap motor drivers and check and swap arduinos and check. And see if I can determine by process of elimination....

Thanks!

Ok... I’m at a loss. I changed the arduino out with an arduino mega (that’s all I had). Changed it in settings and uploaded the code from post 535.

Press up button and the head will go up but never stops. Until I hit kill switch.

Press the down button and the head will go down until I hit kill switch.

I thought I had the encoder signal wires backwards again, but I have changed them and no luck still does same thing.

It is almost like I am not getting any reading from the encoder? I tried to adjust the code to just have it read the encoder and print to serial when the encoder moved. I wanted to move the encoder by hand and see that I was getting some kind of reading from the encoder, but no luck.
Any ideas?
Thanks!

The code you are using uses this register reading which is for the UNO

void isrCount()//interrupt routine for encoder
{
  byte AState = bitRead(PIND, encoderA);//bitRead() faster than digitalRead()
  byte BState = bitRead(PIND, encoderB);

Pins 3 (INT1) and 4 are not at these register locations on the mega. I think the interrupt registers you use to start and stop interrupts are the same, but I will check.

For now, the easiest thing to do is just replace the bitRead() with digitalRead()

void isrCount()//interrupt routine for encoder
{
  byte AState = digitalRead(encoderA);
  byte BState = digitalRead(encoderB);

There are some mistakes in 535 code which were corrected in the code posted 639. It's better to start using the later posted code.

Ok, I am at a loss again. I went ahead and ordered a couple more UNO's. I figured there was no sense in me getting messed up with the differences in the boards in this project. So, I got a new uno in and uploaded the code that is in post 639. Connected it all up and the motor driver will cause the head to go down when the the downQuarter button is pressed, but it does not stop... When the upQuarter button is pressed it does nothing. When either buttons are pressed, the serial recognizes it and prints the lines as it should, but something is not working correctly otherwise.
I am positive it is on my end. I am assuming it has to be in the wiring or motor driver or something. I have tried two different motor drivers and now another arduino.
That seems to narrow it down to the wiring... But I haven't really changed anything that I can remember. I swapped the Rpwm and Lpwm around on the motor driver.
Is there a way to have the serial print when pins 5 (RPWM) and 6 (LPWM) go low and high?
And/Or pins 3 (encoderA) and 4 (encoderB) go high/low in order to see what is not getting read?
I feel like it has something to do with one of those two things..
Thanks!

Welcome back.

For the encoder, here's a simple test to see if there is output from the encoder reading pins 3 and 4.


#define encoderPinA 3
#define encoderPinB 4

byte readingA = 0;
byte readingB = 0;
byte last_readingA = 0;
byte last_readingB = 0;

void setup() {
  Serial.begin (115200);

  //pinMode(encoderPinA, INPUT); //with external pullups
  //pinMode(encoderPinB, INPUT); //with external pullups
   pinMode(encoderPinA, INPUT_PULLUP);
   pinMode(encoderPinB, INPUT_PULLUP);
}

void loop() {
  last_readingA = readingA;
  last_readingB = readingB;
  readingA = digitalRead(encoderPinA);
  readingB = digitalRead(encoderPinB);
  if ((readingA != last_readingA) or (readingB != last_readingB)) // a or b has changed
    // if(readingA != last_readingA) //only a changed
  {
    Serial.print(readingA);
    Serial.print('\t');
    Serial.println(readingB);
  }
}

You may miss some counts, but you should see the output. Ideally you will see
a repeating pattern.

11
10
00
01
11

Additionally, you can add a print out to the isr. This is very bad practice and may cause issues, but try and see if you can get away with this change to the isr where count is incremented/decremented

if (AState == BState)
    count++;
  else
    count--;
  Serial.println(count);//may cause problems! 

Regarding the output on pins 5 and 6, there is an issue with trying to read a pwm output with digitalRead(). I assume you want to see if the signals are getting to the inputs of your motor driver. Perhaps you can place an led and resistor to ground in parallel with the connection to the motor driver. I would think that you should be able to see the led if the signal is going to the motor driver.

Connected it all up and the motor driver will cause the head to go down when the the downQuarter button is pressed, but it does not stop... When the upQuarter button is pressed it does nothing.

If you change the code for the up and down pins, can you get it to go up and not down? Does the problem follow the pin?

//const byte R_PWM = 6;//if this pin goes high and L_PWM goes Low winch will engage clockwise
//const byte L_PWM = 5;//if this pin goes high and R_PWM goes Low winch will engage counterclockwise
const byte R_PWM = 5
const byte L_PWM = 6;

Ok the encoder wheel is being read and written to serial with the code you provided to check it. It was 101010101010..... I was rolling it by hand. So, I guess that eliminates that.

I tried changing the code so that R_PWM = 5 and L_PWM = 6, and it did nothing.... It would not go up or down with either button presses.

I can reverse the wires that go from motor driver to winch and it will let up with the down button press, so, that should eliminate any thought that the winch or wiring to the actual winch is not working.

I didn't have time during my lunch to try the other suggestions, I will try them this evening.

I feel like it is something simple, and I think I will find out why it is not going up, but I just can't wrap my head around why the head isn't stopping when it is going down now.... I even reversed the signal wires from the encoder to just make sure I didn't have them backwards, but it didn't make a difference. I have reversed the Rpwm and Lpwm from the motor driver that are going to pins 5 and 6 of the arduino, still not stopping...

No, that is not a correct pattern.
The program should print in pairs, and the pattern should be

11
10
00
01
11

I am not convinced the encoder is being read correctly, and since everything depends on a count, we need to make certain the encoder is wired and working correctly.

I apologize for this being drawn out and piece milled together. I thought I was going to be able to work on it a little more and more consistently, but I have been much busier than I had planned to be...

The encoder apparently isn't reading correctly.

With the wires connected correctly to signal a and b

I get alternating 101010 in the left column and all 1's on the right column.

So, what could this be? This wouldn't effect the head not going up though would it? It would simply make it not cut off when it is supposed to, correct?

Thanks

I think you are correct. The fact that you only move down and not up is a separate issue.

Make certain that the pull up is connected to the B pin (the one showing all 0's). Check for a short to ground.

I haven’t posted much, but I have been playing around with the arduino, code, and dc motor drivers. I have several projects that I want to do and I figured I needed to learn a little bit so I’d know what the heck y’all were talking about.
We got chickens for the kids Easter. So, I had to build them a coop. It took a lot longer than I expected... but naturally, as @tylerltr450 told me, I thought of a way I could incorporate an arduino in to the coop. I wanted a door that would automatically open in morning to let them out and close at night. I had time to figure out the coding (simple for y’all, difficult for me) while I was at work, and I think I basically have it going like I want it.

@cattledog, I know you probably want to shoot me for getting side tracked again, but I promise I’m not giving up on this project. Please don’t give up on me lol.

Back to this project (kinda). I have been using the 43a motor driver (from Amazon) to run the winch on the sawmill. I think it is under powered. I have tried to “help” it as much as possible with shorter wire lengths, but it still gets really hot! I think (not sure) it has lost some functionality on the sawmill. I believe it is the reason the sawmill would go one direction but not the other. I still need to sort out the signal issue from the encoder as well.

I use one of these:

PWM DC Motor Speed Controller, DC10-55V/60A with Forward-Brake-Reverse Switch, Ajustable Potentiometer & LDE Digital Display https://www.amazon.com/dp/B095PLGK9Z/ref=cm_sw_r_cp_api_glt_i_EZF96XM75MS7KXNNCVE9?_encoding=UTF8&psc=1

to move the head up and down the track and control the speed with the potentiometer. It has always worked really well. Since I haven’t been able to find any readily available (low priced) high amp motor drivers, I was wondering if I could use something like this to control the winch to lift the head.

I started reading about them and saw where the pwm of these boards are controlled with the potentiometer through a 555 timer chip. I see that some people have “hacked them” and soldered a wire to the output pin of the 555 timer chip and can control the pwm with an arduino. (They cut the trace coming out of the output pin of the 555. I assume this bypasses anything coming out of the chip, and it allows the signal to come from the arduino once it is soldered on).

This got me thinking. Would this be a better route to go? I think I can find higher amp boards this way and the lugs/connections are much more suited for the size wire I have/need.

The other question about doing this is changing direction. The board changes direction with a toggle switch that controls a relay. The toggle switch brings one of the legs to ground to select the desired direction. I would have to do this with the arduino. I guess this would need to be done with a separate relay board? Because I’m guessing the arduino isn’t capable of “selecting” the desired direction on its own? Or is there a better way to do this?

Again, i know I’m kinda off track, but If I can’t get anything reliable to lift the head up and down all the work that y’all have done to help me will be in vain. As usual I am open to suggestions, and I am very very thankful for all your help! It has really been fun yet frustrating learning a little about how this stuff works.
Thanks!

Welcome back. Yes, there's more to life than sawing logs.

Moving from a 40 amp to a 60 amp motor controller certainly can't hurt. But I'm not certain you have ever really characterized the new lift motor and what it requires. How do you know it doesn't need 100 amps?
What is the hp rating? What is the stall/start current? The 60 amp controllers appear designed for 3/4 to 1 hp motors.

Modifying one of the readily available, low cost controllers available on line is certainly a way to go.

I have seen some video where a 60 amp board with the 555 controller is hacked to be driven by an Arduino. I'm unclear if all the different controllers use the same potentiometer controlled 555 generated pwm.

Direction control does not seem a major obstacle.

Alternatively, you can go the higher end route and use something like the roboclaw solo 60 Amp from BASICMICRO. I have seen them on line from various suppliers from $100-$110.

I just found the spec sheet on my winch. It is a 2500 lb badland winch from harbor freight. According to the sheet, at 1000 lb (should be within what I am lifting) and one line of rope (I think i have about two “wraps” around the spool) the amp draw is 55 amps.

That being said the 43a motor driver I have may be right on the limits of working.... which I guess is the case. Because I know it will work just not sure how long.

As for the 60a one I referee to, I have an old one that lost part of its functionality as well. It would drive the motor, but the potentiometer that adjusted the pwm would not allow for lower duty cycles. As soon as the potentiometer would click “on” the motor would start at about 90% power. You could turn the potentiometer all the way up and you could see that it would adjust motor speed from about 90 to 100, but nothing lower than 90%.

I decided to try the hack with this bad board that I am sure you were referring to. It was a robojack video on YouTube. I thought maybe it was just the 555 chip that was bad and I would be able to have complete control of the pwm again with arduino..... no such luck. The hacked version of this board works just as the potentiometer. I can adjust it via code and arduino, but there is no noticeable difference in the speed of the motor from 0-90.... however, I could tell a difference from 90 to 100 when I would adjust it in the code.

This makes me believe I am capable of utilizing one of these boards. I don’t really know what is wrong with the board for it to have this issue? Would it be the mosfets are bad?

I like the idea of using these boards bc of the simple wiring that it needs. And price. However, I did look at the driver you provided. It mentions something about a quadrature encoder. Which is basically what I’m using with my encoder right? What does it mean?
Thanks!

It's certainly worth giving one of the 60 amp boards a try--cheap, available, and a well documented hack.

In regard to the RoboClaw Solo, there is clearly some sort of microprocessor built into the unit, and I think it has the ability to read the inputs from a quadrature encoder.
The RoboClaw can be interfaced to either a Windows PC running something called BasicMicro Motion Studio, or to an Arduino. The RoboClaw Solo responds to serial commands from either the pc or the Arduino.

It's probably not what you need, but its what I found at a reasonable price while researching 60Amp industrial controllers.

Ok. I am going to give one of the cheap boards a shot. If nothing else it will be another learning experience. I have ordered one and will come back with my questions when it comes in.

I am curious to why you think the current 60a motor driver i have will only adjust the pwm from 90-100, but won’t adjust it lower than about 90%. Would that be faulty mosfets? Or something else?
One reason I ask is I am considering using it with my chicken coop. It is an entirely different project so I guess I should start a new thread.
Thanks!

A new thread would make sense. Also, be aware that there have been multiple coop threads here before if you need inspiration.

I bet none of them needed a 60 Amp driver to open the door though - that's hard core!

HAHA! Well, the one I have I think is actually 40 amp not the 60 amp version. But still overkill I am sure. I tried the L298 but it wasn't enough to lift my door. So currently I have the same BTS7960 that I have been trying to use to raise and lower the sawmill (Its the last one I have I think. I have been through 4 on the sammill..... :blush: :roll_eyes:

I will explain what I am thinking about coop door idea in new thread. My mind is kind of like a ping pong ball it bounces all over the place.

Thanks!