Can someone fill me in the purpose of the stop button on Ground Control. I had a reason to stop the machine in the middle of a run. I pressed Stop which did stop the movement, however I was not able to do anything after that until I restarted Ground Control. This seems like a bit of problem. Am i missing something? How do I control the machine after pressing Stop without restarting GC?
‘Stop’ immediately terminates movement and the cut. It’s a bail-out button. ‘Hold’ finishes the gcode line currently in progress and then waits suspended until you ‘Continue’ with the cut or ‘Cancel’.
2 Likes
I wanted to add to this topic. I’ve been playing with my kit , learning the software and also noticed funky actions with the STOP button. When I click it, it stops the motors. But if I then go try and manually move , the motors are very jerky and sound like they are binding up. The fix is obviously to restart Ground Control. But I just wanted this pointed out in case moving after a STOP might be hurting the motors or the maslow shield drivers. Using 1.0
I might add, after a bit more playing around. It seems the funky sounds I’m hearing might be normal. Though I swear when I first moved the motors it sounded cleaner, like it sounds when you run the TEST MOTORS function.
Does the TEST MOTORS function inherently sound better than when using the manual move
That’s very interesting. I’m trying to replicate what you see and I’m having trouble making it happen. This happens if you say click the left button, then before the machine has finished moving you press the ‘stop’ button, and then press the left button again and the movement has become jerky?
Here is a video. So I clicked move 8 inches downward at the start , then clicked the STOP button about 4 seconds into video. Then you can see how the sound and movement changes when I click move 8 inches again.
BTW, it took me two tries this time at clicking stop during a move, to get it to sounds (different)
Maybe it has something to do with me not having calibrated any machine numbers yet?
1 Like
My instinct says that this could be related to our other outstanding mystery at the moment which is this strange behavior:
https://forums.maslowcnc.com/t/are-these-normal-behaviors/?source_topic_id=521From the video it looks like it’s mostly one motor which is showing the issue, is that right?
Both motors definitely exhibit a slower jittery sounding movement compared to the faster smooth movement prior to the STOP.
Strangely, I couldnt get the issue to revert even by restarting Ground Control, repowering arduino, even trying 0.99 firmware.
I then went into actions and went thru the first step in calibrating machine, backed out of that. Then went into calibrate chain length, which I did nothing but just click through. At end, it leaves one motor running (still noisy). So I closed Ground Control, reopened which stops that motor. Then Magically, the motors run smooth again.
1 Like
This is so weird! I really have no idea what is going on but I’m going to keep thinking on it and see if I can figure anything out.
I’ve created an issue to describe what you are seeing in github here
Would you do me a favor and give version .98 a try and see if the issue goes away when you go that far back? We’ve been seeing more strange behavior since .99 that I can’t explain so .98 might fix it and if it did then we would know where to start looking.
2 Likes
So this is very odd. I would be surprised if this was PID related since it somehow goes away with software changes. I don’t have a good guess at the moment, but I am interested to see if .98 fixes anything.
I am a little uncomfortable testing things when in a non-normal state. The default settings in GC should be fine. (??I think has anyone checked that?) But when you say you just clicked through the chain calibration step, as long as you let the motors think they are extending chain we should be ok.
Well I’d love to test that out for you guys, but this morning when I started to play with it … gasp… one of the maslow sheild driver chips lost its magical smoke 
I guess I could try it with one motor still working. I’ll let you know…
Well I’m still baffled. I’m going to try a different Arduino board at some point down the road. Plus with a blown motor chip, I don’t know if that and its 0 chain length setting is compounding my issues.
One thing I noticed that seemed odd to me on the o-scope, when the motor was doing the jerky noise, there were V+ pulses on both M+ and M-. Depending on direction, one side would not have as big a pulse as the other.
Compared to when it ran smooth and were no pulses on the - side.
If you are traveling one direction, you wouldn’t want V+ on the minus side right? I can’t think of a reason otherwise, maybe unless it does some tuning or reversing a tad?
I completely agree, we shouldn’t be seeing be seeing voltage pulses of both polarities on the same lead at the same time. Why did the board blow up? Did something bad happen to it or did it just blow up for no reason? Best case scenario it was a bad board (although it really sounds like a software issue to me). If you send your address to info@maslowcnc.com we’ll send you a new one so we can at least rule the board out as a factor.
Thanks for taking a look at it with the scope, that’s really valuable information to know help figure out what is going on.
This sounds like your PID settings are incorrect and it’s overshooting where it
is supposed to be and backing up.
I keep vacillating between wanting to say it’s an issue with the PID expecting to see a load on the motors so it’s overshooting then correcting, and wanting to say it’s an unrelated software thing because it has to do with the stop button being pressed.
It could be that stopping the motors suddenly is leading to integrator windup (or something similar) which is making the movements jerky making it a PID issue which is triggered by the software
I’d like to add at the end of testing around, I don’t think the stop button had any effect. It would start happening at will. Even during a smooth move.
1 Like
Are you still seeing it with one motor? If so we might be able to test some things to get it sorted out before your new shield arrives
that makes a lot of sense, when stop is issues, things can’t stop instantly, so
the position that you are at is not going to be the desired position.
after the stop command, re-calculate your position based on the actual chain
lengths, and any time you are starting from stopped, be sure to clear the PID
state
1 Like
None of this makes any sense.
We don’t have integrator values, so nothing ever winds up.
When a stop command is received in the firmware, it looks to see what the current encoder positions are and then commands a movement to these positions and keeps the motors on for two seconds so they can lock into this position. This is why the stop is instantaneous rather than a slowdown when you cut power to the motors.
I don’t think our default PID settings could do this, and I would be a bit surprised if there was a value that enabled it operate normally in some instances, but would destroy the bridge in another instance.
I am really stumped.
Yes the same with one motor. However there’s a new strange behavior. Sometimes it runs smooth and in one direction no matter which directive move I click in GC. Then it’ll go into jittery mode at will and then goes correct directions.