I haven’t seen in any post so far the exact type of problem that I am having so I figured I would start a new topic and see where this takes me.
So, I set up the Maslow a few weeks ago and everything seems to be working well. I later added the z axis control with a motor that I found on Amazon that others posted they had used in the past with good success. The problem that I am having is that whatever command I give use in Ground Control (GC), the z-axis motor will change the motor rotation direction. (ie if i tell it to go up 100mm, it rotates clockwise, if I tell it to go another 100mm it will rotate the counterclockwise and it switches rotational direction regardless of the command given)
I have purchased everything but the z-axis motor from either Maslow or maslow surplus parts so the motor is the only thing that is unique in my particular setup. Here is the pin connection layout.
I did notice that the GND and V+ pin order was switched as well as Sensor GND and Vcc so I made sure to switch those before connecting to the Aurduino.
Next thing I tried was trying a different motor so I connected a x/y axis motor to the z-axis cable. I changed the settings in GC for the different encoder PPR and gear reduction and everything worked perfectly. Reconnect the z-axis motor and it oscillates back and forth . . .
Next I thought, “hey, maybe the encoder is bad, I should get a new one and try that…” got a new and same thing. . .
When I run the motor check feature in GC, the z axis motor fails the test. . .
I am running GC on a laptop with windows 7 and I also use this laptop to run Flashcut CNC software on another CNC machine.
I’m not sure of where to go from here and would greatly appreciate any help I can get.
Good troubleshooting.
I use the upgraded TLE board and made my own cables and connectors. When I went to connect the x/y motors, I thought that the hall +/- pins were swapped between the board and motor. I had some strange issues that sort of sound like this, although it’s been awhile. I ended up putting them back and it worked. Not sure this would fix your issue but it does sound like a wiring/polarity problem.
What error did GC give?
I think an approach to narrow this down could be to get GC ‘in a stabe state’ and only use the z-menue and report back the reaction plus what GC thinks it’s doing by recording the Z-positions (or picking that parts from the log). Guess that will make the picture more clear.
This is all with router and vac turned off, right? So noise from power wires can be excluded?
Edit: 1 more question. What are the settings you altered in GC and to what value?
Sorry for the delay in responding, it don’t get time to go out to the shop every day so I needed some time to get back to it. Also, I have been doing all of this with the router and vacuum off. Just moving the sled around.
So here is what I found:
When I ran test motor/encoders function under “Actions” in GC, the z-axis motor would fail the test in both directions (the motor would move both direction though).
I tried switching the Hall Sensor A & B Vout as someone had suggested and the motor hummed but didn’t move. So I switched them back.
Then I went back and switched the Hall Sensor GND and Vcc to duplicate the error that I had reported. At this point the z axis began responding properly to the command inputs in GC and seems to be working properly now.
So it appears that I missed that for this motor to be used, you have to switch both motor +/- AND Hall Sensor GND/Vcc.
Hopefully this information helps others who screw it up like me
Now that the motor is turning the direction I tell it to I have been working on getting it to move the router the right amount (ie if I tell it to come up 1/8 inch, it moves that much)
Here are my settings: Pitch: -3.175 (I am using the standard rigid router here) I made it negative to switch the motor direction Z-Axis Encoder Steps per Rev: 6300.8 (Encoder 16PPR with 393.8 gear reduction)
All other z-axis parameters are still at the default settings.
Here is what it is doing. I tell it to move down 0.125" (which should be one revolution of the z axis shaft based on the pitch of the rigid router) and it rotates nearly 3 full revolutions. I started messing with the PPR in setting and they don’t really seem to change anything. I changed it to 100000 PPR and it moved exactly the same amount as before.
Next I tried playing with the pitch to see if that had any effect. This seemed to change things but I had to change the pitch up to 75mm/rev and after that it didn’t seem to change anymore. but is was pretty close to 1 revolution which was what I was looking for but its still not right.
I then thought “hey do an encoder test”, so after doing that it is still failing the z-axis encoder in both directions.
It seems to be a dual-hall sensor. Sensor A/B suggests its 2. They are very close together though.
With the original Maslow z-motor with 2 separate sensors i’d expect the ‘phase-shift’ to be more clear.
This is more of a question: Would noise on the wires have more disturbance on a sensors that are closer together? But didn’t @clintloggins get this motor to run??? And how?
only 16 ppr on the encoder? that seems odd, given that one position on the
encoder wheel produces 4 pulses, that would be an encoder wheel with only 4
positions. Since you are moving a lot further than you intend to, it’s more
likely that it’s 16 positions, which would be 64 pulses/rev
the location of the sensors around the wheel doesn’t matter, all that matters is
that they are offset by 50% of a step (as is shown in your scope trace). Any
encoder that gives you A/B outputs is going to be offset like this.
looking at the Amazon listing, try using a PPR value of 64, each channel (A and
B) gives you 16 pulses/rev, but that results in 4 state changes per pulse.
The location of the sensors is what gives the phase offset, placing them a 90 degrees is for optimal offset.
If the encoder has only one sensor (pic looks like an US5881LUA), there is no way to sense direction.
One sensor per channel.
if changing Z encoder steps from 6300.8 to 25203.2 doesn’t change how far the Z axis moves, then you are not getting the change saved and into the firmware.
it may not be correct yet, but it should make a huge difference in how far the Z axis moves when you tell it to move the same distance.
I’m sure that is possible but when I go back in and check in the Advanced Settings the input is there and there. I have shut down GC and restarted to see if that made a difference and the PPR that I changed it to is there and it still behaves the same. I’m thinking that is has something to do with the encoder still failing the test. It seems like GC doesn’t know what the z axis is doing. . .
but is was pretty close to 1 revolution which was what I was looking for but its still not right.
