Moppy with other types of steppers

[MuffyTarkin]

Not sure if Sam or the usual contributors and modifiers ever come around here anymore, but I've been experimenting with this awesome little program for the past few months. I've been able to successfully get other variations of stepper motors other than those found in floppies to work with Moppy.

However, I've hit a snag and was hoping for some help. I can get big steppers to work fine with my current controller. My problem is I want to use something like a scanner. I think it would fit with the computer aesthetic. I can get the scanner to work and play notes, but the blasted thing just moves back and forth very very quickly instead of taking full strides down the length of the track.

I figured this had something to do with the MAX_POSITION line in the first pin array, so I spent the last 30 minutes adjusting that. I went through lots of values. I tried very high values just to see if it could go further than it already has, tried really low ones. I know my adjustments do SOMETHING, because at very low values it barely moves at all. However, it seems it does not go past the default MAX_POSITION of 158.

Any higher than this, and it's like no change has been made. I've found if I bring it freakishly high (around 800), it is treated as if it's a very low value (I'm assuming this is some kind of arcane integer wraparound magic with the Moppy IDE).

My question is, is there any way I can get this to work correctly? I went poking through the Moppy IDE to see if there was anything about MAX_POSITION and I could not find much. On the other hand I don't know a single bit about Java other than my intro to webdev teacher telling us it was a DOM.

I know I could utilize a system of limit switches (I was thinking of using hall sensors for this) but that is a lot of extra wiring and dedicating a pin to just a hall sensor. I know a software solution has to exist for this, I just don't know how to make it happen.

[solidsnake745]

You're absolutely right, you can use this code for many kinds of (if not all) stepper motors. I've been using it myself lately to drive some NEMA 17 stepper motors. I've also been working (very, very, slowly) on building a library so people can more easily connect and configure different steppers for use with Moppy and hopefully other applications.

I believe the issue is that MAX_POSITION and currentPosition arrays are both byte type. So the max value they can store is 254. When you try and assign a higher value, I've seen the value being returned being -1 (due to overflow). You might be able to verify this by throwing in something like this in your setup and seeing what comes back in the serial monitor: Serial.println(MAX_POSITION[2]);

Try changing both of those arrays from byte to int so it can store your higher values. Just to be explicit:

From: byte MAX_POSITION[] = { 0,0,158,0,158,0,158,0,158,0,158,0,158,0,158,0,158,0}; byte currentPosition[] = { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};

To: int MAX_POSITION[] = { 0,0,158,0,158,0,158,0,158,0,158,0,158,0,158,0,158,0}; int currentPosition[] = { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};

[MuffyTarkin]

Oh wow, I was not expecting such a fast response. Thank you! I figured it had to store them as bytes since going above 254 seemed to cause it to go backwards. On the other hand I could have just looked at the array though. The woes of working on stuff at 3 AM. Thank you so much!

I've found a good integer butter zone, and I'm assuming this minor conversion won't change how the floppies operate since 158 in a byte value is still going to be the same in the integer value, correct?

Now I just need to figure out how to get it to go all the way back to zero instead of moving a little bit when I reset it. If I stop it when it's close to 0 it's fine, but if I stop it when it's closer to the end it doesn't go all the way back. It's not so bad the way it is. Kind of humorous because to reset it back to zero I have to cut power and move the scan head back to the beginning. Kind of like a typewriter. It's funny. But still, I'd rather not have to do that.

I'm going to assume it might have something to do with this? // New all-at-once reset for (byte s=0;s<80;s++){ // For max drive's position for (byte p=FIRST_PIN;p<=PIN_MAX;p+=2){ digitalWrite(p+1,HIGH); // Go in reverse digitalWrite(p,HIGH); digitalWrite(p,LOW);

I really don't know a whole heck of a lot when it comes to Arduino sketches. I mostly just poke around in places that seem to make sense and change stuff and see what happens. From what I'm looking at there, it looks like I might have to change byte to int as well? And obviously adjust some of the numbers there. I'm not sure what p+=x does, but just guessing that looks like it's taking the first pin value and just adding an integer to it? It looks like P is defined by byte p=FIRST_PIN; and then it is checking if it's less or equal to PIN_MAX, and if it is, it's adding 2. Okay, so that must be so it just goes down the line and resets all the drives, right? Plus 2 on the step pins, so it covers every even pin. Plus 1 on the direction pins from digtalWrite(p+1,HIGH); instructing each direction/odd pin to flip states and go backwards.

So it must be getting the movement value from for (byte s=0;s<80;s++), where S=0 is, well, 0, and it's checking if s is less or equal to 80, and if it is...just add one to it? Not sure how that gives enough info on how far to move the motors back to zero.

Sorry for this long reply, I'm just kinda thinking out loud while I down some coffee.

EDIT Yep, looks like I was right. for (byte s=0;s<80;s++) does indeed specify the step length for going back to 0. I think I'll leave it where it is, because changing that will play hell with resetting the floppies and plus it takes ages for the scan head to go back to 0 from the end of the track when I tell it to reset from there. Having to manually push it back if I decide to stop it in the middle of a song is okay. Like I said, it's humorous.