S221B

Forum Replies Created

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • March 13, 2023 at 2:42 pm in reply to: Weird Behavior After Completed Job #12168
    S221B
    Member

    Everything you just said makes perfect sense to me. I think we might have been “talking past each other” with how we were describing Z-min and Z-max and the correct homing routine, but I am 100% aligned with “home Z to zero, all Z motion downward is negative”.

    I’m becoming increasingly convinced that the error might be that my G-code, which executes all of the moves (finishes cutting the part successfully), is actually getting stuck in the final couple lines at or around the M30 command, and this is what’s causing the quirks.

    I will update this post after bug-checking so that other users may reference this if they encounter the same thing. Thanks again for all of your help!

    March 13, 2023 at 11:56 am in reply to: Weird Behavior After Completed Job #12166
    S221B
    Member

    I will follow up on your questions A, B, and C tonight if I can get out to the shop.

    Regarding your statement that having a Z-max switch and homing to Z-max is unusual – I guess I am just surprised by this. I suppose that most users must therefore home to Z-min. I never thought about this too much (I have switches on both Z-min and Z-max), and I home to Z-max because then I never have to worry about crashing a long tool into the table while homing, and it gets the spindle up out of the way for attaching/removing a workpiece.

    Another theory (which I will test) from a co-worker is that the M30 command at the end of my G-code file is “getting stuck”, and that the machine is actually pausing at the end of the file rather than completing. I can imagine that running a G28.2 in this condition (which the machine regards as the “paused middle” of an incomplete G-code file) might cause screwy behavior. I will test this more thoroughly.

    Thanks for all of your input so far – as problems go, this isn’t too bad, as I am still able to run and complete jobs – but as an engineer, I hate unsolved mysteries and ghosts in the machine.

    Cheers!

    March 13, 2023 at 6:57 am in reply to: Weird Behavior After Completed Job #12164
    S221B
    Member

    To clarify and address your questions:

    1) It was a typo in my original description of step six; the homing is done with the usual command G28.2, not G20.2 as I had originally typed.

    2) I do indeed have a limit switch at the top of Z travel, which is triggered normally when homing the Z axis. The machine is, indeed, a three-axis gantry type machine, with X+ moving away from the operator, Y+ moving to the left, and Z+ moving upward. (A conventional “right-handed” coordinate system.)

    3) When jogging in step 3, I do move the Z-axis downward to a negative absolute coordinate location. When I then use G92, it sets offsets to make the new location (with the tool now located relative to the blank) 0/0/0 in the working coordinate system. (I believed that this was normal practice.)

    To clarify the problem – in step six, when I go to home the machine after completion of a job with G28.2, the Z-axis travelling upward, bumping the switch, and the retracting is normal (not a problem) for homing. The odd behavior is that the X-axis, which then *starts* to move toward its home position, stops moving before it actually contacts the switch, and then the Y-axis (which would typically home last, after X) doesn’t move at all.

    No error shows up when X stops moving. Re-issuing the G28.2 command after this “incomplete homing” then results in normal behavior; the Z-axis moves/bumps/retracts, followed by X, then followed by Y.

    It’s like something is stopping the normal homing routine, but only in this specific condition, and the absence of an error code is baffling.

    December 4, 2019 at 2:50 pm in reply to: Motors stop but TinyG thinks everything's OK #11701
    S221B
    Member

    Well…the mystery now seems solved. There were actually two things going on.

    In search of a ground fault, I opened up the control box for the machine. (My TinyG board, power supply, fan, and jacks for motor and switch connections are contained in a plywood cabinet with a plexiglas top.) I discovered that the power supply, which is mounted to the box with four screws, had just a tad of wiggle in it. (The holes the screws pass through are intentionally slightly oversized.) Apparently, vibration from the machine running loosened them up slightly. This was allowing the PS to move around (maybe just +/- 1mm any direction), but I found a witness mark on it’s aluminum case to suggest it was touching the metal plate on the side of the box where the jacks to the switches are located.

    This plate is connected to the TinyG ground, and thus to PS negative. The exterior of the PS is connected to earth ground. Thus, when the PS touched the metal plate, I was intermittently connecting PS negative/TinyG ground to Earth ground.

    By itself, this shouldn’t really matter, but the fact that this unintentional connection was intermittent (as the PS jiggled around in the box) was probably not great, and I suspect may have been confusing the TinyG.

    I stuck a piece of electric tape over the spot where it had touched, re-tightened the screws, and this seemed to fix everything at first.

    As I proceeded with some test runs cutting foam, I found some odd Z-axis behavior was persisting. Upon inspection (thinking of how the PS had loosened up) I discovered that the connections to the motor wires on the TinyG board had loosened a bit, and that Z was particularly loose. I snugged them all back up now everything seems fine – I ran several jobs without incident.

    The moral of this story:
    1) either ground your PS negative to earth, or don’t, but don’t let it intermittently jump around.
    2) fasteners loosen with vibration
    3) if the motors are acting weird, double check all connections from the board all the way to the motor

    I’m just happy to have everything working properly again!

    November 27, 2019 at 10:06 am in reply to: Motors stop but TinyG thinks everything's OK #11691
    S221B
    Member

    Update:

    Well, with the chassis lead to Earth ground removed, everything seems to be normal now. I ran a full Gcode file with no issues, homing is back to normal, jogging is fine.

    I am utterly baffled how I managed to create enough EM interference to disrupt the TinyG by grounding the chassis…I would have expected exactly the opposite. That being said, it’s not broken, so I’m going to stop fixing it!

    November 25, 2019 at 5:34 pm in reply to: TinyG not reading arc commands correctly? #11688
    S221B
    Member

    You might find this earlier post informative:

    https://synthetos.comtopics/arc-specification-errors-and-decimal-accuracy

    I had problems with the arc commands myself…now I generally just post-process to make Gcode files that omit the arc commands. Instructions on how I did it are included if it’s helpful.

    Since I did this I haven’t had problems, even if the Gcode files are longer, it doesn’t seem to impact run time or cut quality.

    November 25, 2019 at 5:29 pm in reply to: Motors stop but TinyG thinks everything's OK #11687
    S221B
    Member

    Update – I didn’t have much time tonight, but I disconnected the lead that was linking the machine chassis to Earth ground. This Earth ground connection was the same one used by the 24V power supply, just further upstream.

    I did a number of jogs and homing cycles and everything seems normal so far – no mystery stalling or weird behavior. I will try to run a part tomorrow.

    Here’s the real stumper – whatever was going on wasn’t triggering the limit switches; there was no blinky light and no alarm status on the machine. The machine acted like everything was normal. The only thing I can figure is that whatever combination of ground loops I created was inducing a back-EMF in the motor leads that was preventing the field coils in the steppers from energizing. I can’t think of anything else that would have caused this.

    I’ll play with it again tomorrow and report what happens.

    Cheers!

    May 12, 2019 at 5:04 pm in reply to: Arc Specification Errors and Decimal Accuracy #11418
    S221B
    Member

    Update:

    Well, I dove into the Fusion 360 post-processor. I am not a JavaScript expert, but I did recognize one line that seems to control the number of decimals in the output.

    (I include this for the benefit of anyone else who goes down this path.)

    The stock line is:
    var xyzFormat = createFormat({decimals:(unit == MM ? 3 : 4), forceDecimal:true});

    This means “if unit is set to MM, use 3 decimal places for xyz values, else use 4”.

    I tweaked it to read:

    var xyzFormat = createFormat({decimals:(unit == MM ? 4 : 4), forceDecimal:true});

    This forces mm-unit output to have four decimal places instead of 3. I could have changed the second 4 to a 5, but I never work in inches so it’s irrelevant to me. (Changing it to 5 would force inch-unit output to have an extra fifth decimal.)

    I also found the stock line:

    allowedCircularPlanes = 1 << PLANE_XY;

    Which basically enables G2/G3 in the XY plane. I discovered changing it to read:

    allowedCircularPlanes = (0<<PLANE_XY)|(0<<PLANE_ZX)|(0<<PLANE_YZ);

    This has the effect of disabling G2/G3 on all three planes and forces everything to be linear (G1) moves.

    There may be a more elegant way to make these tweaks (as I said, I am not a JavaScript expert, and this is my first try editing a post processor) but I figured it was worth sharing.

    Cheers!

    May 5, 2019 at 5:23 pm in reply to: Connected, but can't send Gcode files #11412
    S221B
    Member

    Hi – one final update – I ran again with “enable hardware flow control” NOT checked on CNCjs, and with $ex=0 on the tinyG. Everything seems to work fine. From what I can tell, CNCjs just needs that init string ($ej=1) to get everything working fine. I can’t immediately tell a performance difference between “hardware flow control enabled” or “not enabled” modes, but I haven’t been cutting any really difficult parts, so perhaps the difference may be evident in a file with many short-duration moves that doesn’t show up in files with simple long-duration lines and arcs.

    The take-away: if you can’t get CNCjs to work, ensure that you set $ej=1.

    April 27, 2019 at 11:06 am in reply to: Connected, but can't send Gcode files #11408
    S221B
    Member

    UPDATE: Problem seems to be solved.

    I am posting this in hopes that it might help others in the future with a similar problem.

    It appears that the source of the problem was not a flow control issue (as I initially suspected) nor a Gcode issue. Rather, it seems that CNCjs needs to have the tinyG set to “enable JSON mode”, and that mine was set to $ej=0 rather than $ej=1.

    I connected to CNCjs as I had previously (incidentally, with the “hardware flow control” check box on, and TinyG set to $ex=2 to match) and initially had the same behavior as before – manual Gcode commands worked, but sending a file would just lock up and do nothing. (In answer to cncmcgrath’s previous question – no activity on the console during file transfer startup.)

    I found that entering $ej=1 in the console window of CNCjs (switching the TinyG from text mode to JSON mode) magically enabled everything else (including sending a file) to operate properly. Interesting, this did not require a reset of the TinyG as the $ej property seems to be switchable during a session with no ill effects.

    I have noted that, in spite of having changed this parameter in the console window, on power-off and reboot it defaults to $ej=0 or text mode.

    For now, entering $ej=1 in the console window at the start of a CNCjs session seems like a minimal hassle, but I am a little puzzled why this change doesn’t seem to persist on reboot like all other config parameters.

    I may try connecting with hardware flow control shut off (and $ex=0 on the TinyG) as an experiment later this weekend, as I am told that using hardware flow control is a less elegant method than software flow control. I will update this thread with the results when I do so.

    Thanks for the help! I hope this thread is useful to others in the future.

    April 24, 2019 at 7:21 pm in reply to: Connected, but can't send Gcode files #11403
    S221B
    Member

    Thank you for your prompt reply, it is most appreciated.

    I tried setting $ex to zero, resetting, and then connecting with CNCjs. The results were the same – I connected, homed the machine, did some manual moves with command-line G1’s, zeroed the machine with a G92 X0 Y0 Z0, loaded up a Gcode file, saw it in the visualizer, hit send…and nothing.

    I *did* note that in this condition, the tinyG is unresponsive. Hitting pause and cancel on the CNCjs interface, however, returns the tinyG to a state where it will accept commands and return status. It’s as if CNCjs just kind of “stalls” when trying to send the file.

    I also tried with UGS (both versions) and got the same result – it doesn’t seem to “see” the Gcode file, and reports it as having zero lines.

    I am starting to think that perhaps the problem is in my Gcode files (in spite of the fact that they have worked fine with Chilipeppr and CoolTerm?) and I’m going to pore over them tonight…I’m generating all of my Gcode with Fusion360, using the regular tinyG post-processor.

    Any other clues / suggestions / insights would be welcomed.

    Thanks!

  • Author
    Posts
Viewing 11 posts - 1 through 11 (of 11 total)