Could I ask for some more debugging help?

Could I ask for some more debugging help?

grbl 0.9j
arduino uno
gShield v5
SJPS 1.93 osx

I am coming across several oddities that I have not managed to chase down in the grbl code. as follows:

  1. when the job is forcibly stopped (with the red square and then the ctrl-x button), 6 times out of ten the axis zero will randomly reset. sometimes it appears that transformation of the axis zero is mirrored on a diagonal. but i think that is appearance only. I have not been able to find any pattern to this.

  2. when running an autolevel job, if it bugs out in the middle of a job or if it is stopped, most times the y-axis zero point shifts by 10mm outside of the board dimensions. some times this does not happen. again, there is no discernable pattern.

  3. every time I tried to run a calibration job (just some vertical and horizontal lines at fixed distances) the serial monitor would disconnect at random intervals. On two occasions causing a kernel panic on my mac. I was concerned that perhaps the bottom of the gShield was shorting on the usb connector but this was definitely not the case (inserted a physical insulator and this still happened.

  4. running the chilipeppr logo job, with no changes, sometimes the job never bit the board, sometimes it snapped the bit off in the board. literally no changes other than restarting the job. As if the z-axis simply didn’t know it’s proverbial arse from its elbow. But … chilipeppr was reporting things correctly anyway.

I’ve tried with a few Unos just in case one had some voltage regulator issues. All the same.

all these things feel like grbl issues (other than the kernel panic which feels like an SJPS issue). But I cannot believe that I am the only person using grbl 0.9j in this configuration. I’m only running 0.9j rather than the ‘stable’ 1.1 branch because it appeared that chilipeppr doesn’t support 1.1 (I have tried it with a number of different settings for position reporting but none have been successful. I wonder whether 1.1 is talking a different language in reporting position data to 0.9).

thanks as always in advance.


P.S. I have a due arriving in a couple of days so will try tinyg2, but that is not reason not to get grbl working.

p.p.s since starting this, a new issue has arisen - the stepper motors (or the gShield, not sure which) are shrieking loudly when engaged and it seems that one of the channels no longer works at all. i wonder whether the gShield is faulty and that is the source of all issues? any way to hardware debug the gShield?

I think stopping with red button and CTRL+X will loose all your coordinates and machine needs homing cycle or at least g28.3 if you know where you are, but if you stop during motion you will surely loose some steps. The axis should be kept same and not mirrored anyway.

There is a bug in sjps on the grbl workspace which possibly might be responsible for some of your issues.

I don’t use grbl after switching to TinyG, but I remember I enabled software denouncing and mostly disabled limit switches ‘limit’ action to avoid false alarms triggering. Maybe you can try this, with a remark that having no physical limit switch on the axis, you really have to think each gcode command three times.

TinyG2 on Due worked fine, except autolevel. I didn’t have chance to check with latest firmware and will try as quick as I get back to my machine (~a week to go).
Testing on ‘Due only’ with no gShield and no cnc connected was always fine and got erratic only on the real hardware with live probing cycle.

For the p.p.s.:
Please check if the motor wires are not loose. I got this problem long time ago and after I made all connections firmly, it works just great.

Thanks Sebastian

i will recheck the motor connections but they appear solid. I will verify electrically. My guess is that a channel is broken though - i disconnected the steppers without first disconnecting the board from the motor power supply (the steppers were not enabled though). this may have caused a spike.

can you point me to the bug on SPJS + grbl? i will try to remedy. It would have to be quite severe to cause a kernel panic.

I have not connected any limit switches yet. I can’t really see how a z- limit switch can work with pcb milling when you don’t know the bit protrusion nor the milling depth at the mechanical level (at the software level you do, of course). of course I can see the value in x and y and z+ limit switches although hitting limits is not a problem I have yet come across, as my workspace is 100*70 and the mill-space is roughly double.

At the moment I am not altogether happy with the mill i have bought (there is significant wobble in the threaded rods on x and y axes, and the z gantry is attached to the x-axis - you can visibly see the gantry moving up and down a few mm as the thread wobbles) so I’m unwilling to do anything too permanent to it before I decide whether to send it back. If i do send it back, I’d probably just buy some maker slide and some ball screws and make my own replacement- but I’ve said that kind of thing before …

@sszafran and any others interested

re the pps… please see the attached video.

the first section of the video is with the x,y and z axes connected properly.
i then disconnect the x axis and you can hear that the whine has gone. then connect the z axis output to the x axis servo to demonstrate that the servo still works.
so the conclusion appears to be that the x channel on the g shield has failed. the external wiring is solid and there is no evident failure signs on either side of the board.
does anyone have experience of hardware debugging the gShield? any likely culprits for component failure? I don’t have an oscilloscope here unfortunately.

missing/deleted image from Google+

Maybe stupid questions, but it’s always good to re-check:

  1. Do you have a chance to measure coils resistance with a multimeter?
  2. Are your settings related to X-axis correct (velocities, step/rev, junction)?
  3. Is the motor wired propely to gShield?
  4. Did you test X axis motor on Z-gShield only? Try opposite, Z-axis motor on X-gShield.
  5. If you have an extra stepper motor avaliable, maybe you could run a test with no load, or release X-axis coupler to run motor with no load?

From what I hear it is exactly the same type of sound what I faced with bad connections to the motor mentioned in my comment earlier.
There is also a chance that something is wrong with the driver.

thanks again.

the whole machine was working then spontaneously stopped when I was doing some probe testing and disconnected the motors. the board was not powered but the motor power was attached at the time.
So the x-axis settings on the gShield have not been changed. But who knows - maybe the uno has corrupted them. I will check.

the x axis motor works fine plugged into the Z or Y axis controller. so the coil resistances are ok.

yes - all wiring to the shield is perfect. firmly connected at both ends.

i can disconnect the coupling but I know that the motor is fine as it works ok with other channels.

So the culprit is logically the channel. What I don’t know is if this is a driver chip problem, or whether some other component issue is there.

@Justin_Adie Well, possibly you need to replace the driver chip on your board. I did it once, after one of my DRV8825 have unexpectedly blown during machine operation. I should have one DRV spare and can eventually send you (from Poland).

Thanks Sebastian. I won’t deprive you of the spare and have ordered a replacement chip already just in case. It is a very generous offer though; I am grateful.