Z Axis issues CBeam XL

Home › Forums › TinyG › TinyG Support › Z Axis issues CBeam XL

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • July 8, 2017 at 2:14 pm #10445
    Nell
    Member

    Hi All –

    Here is a copy of a question I posted elsewhere, and one of the replies. I’m hoping someone could help point me in the right direction here…

    Question for those who may know…
    I’m running a C-Beam XL with tinyg and chilipeppr. When the Z axis goes down for a cut, if it retracts and then goes back down it seems to miss steps. 0.5mm is anywhere from 0.5mm to 3mm to -2mm. Is there a setting or something I’m missing?
    All motors mapped to 1/8 step, 8mm travel per rev, 1.8 deg, with the Z settings at: 400mm/min max vel and feed, junction deviation at 0.05mm, jerk 20 mm/min^3.
    I’m open to any and all ideas. Thanks!

    Reply:
    Your direction pulse needs to be present when the pulse is sent, if not the direction can be seen as changing at the point the pulse is registered and it can accept the step in the wrong or a random direction, so losing steps especially on direction changes or in one direction.
    Lookup the specs for your drives break out board etc and be sure your pulse polarity is correct.

    Does anyone know where I could find this information? The axis moves as directed when given a move command, and is calibrated correctly (10mm = 10mm) but is clearly not doing what it should when it retracts or plunges after the initial dive into the material (MDF).

    Thanks for any help!

    Nell

    July 9, 2017 at 7:35 am #10448
    cmcgrath5035
    Moderator

    Just looked at Cbeam URL so have an idea what you have.

    Assuming you are using tinyG onboard motor drivers, the dir signal will be in proper state when step pulse signal is sent.
    If you are using motor external drivers, please describe them and how you interface to them.

    A look at your parameter set might help – run $$ command from serial port widget, copy and paste the results to a text file, put the text file on a cloud drive and post the URL here.

    Does this behavior (erratic up/down) occur only when running Gcode, or does jogging also misbehave?

    July 9, 2017 at 12:38 pm #10453
    Nell
    Member

    https://docs.google.com/document/d/1ZlzvtuE89gH3OG1X9dOo94GVLs5vcJMqUR_JbweHLBQ/edit?usp=sharing

    There’s the document (I hope). I’m running the tinyg drivers to drive the OpenBuilds NEMA 23 motors.

    I’ve only noticed it with gcode so far. I have the motors wired as:
    Red – A1
    Green – A2
    Yellow – B1
    Blue – B2
    per the layout on OB website (and the r/g y/b pairs make the motors difficult to turn).

    Thank you for the help!

    Mike

    July 9, 2017 at 2:03 pm #10456
    cmcgrath5035
    Moderator

    $$ file is good.

    Comments on $$:
    1. It looks odd to have 2 motors mapped to Y of the same polarity, but that is likely correct assuming the lead screws are the same rotation. Most legacy dual Y machines are belt drive and the Y motors rotate in opposite directions.
    2. Do you actually have a Zmax homing switch? Your parameters enable it.
    If you do, and you use Z homing, then you should set $ztn=-24 and $ztm=0.
    By convention, tinyG homes Z to Zmax and all travel into your work is travel to “-” location.
    More info:

    If you have no Zmax home/limit switch, set $zsx=0
    Note that should you decide to use soft limits($sl=1) then you must make the #2 correction. In this parameter set $sl=0, so not really necessary unless you manually set home on Z.

    Any of this help?

    If not, perhaps post your Gcode to the cloud drive for a look, perhaps something in there.

    July 9, 2017 at 4:03 pm #10458
    Nell
    Member

    So I manually set machine 0 and G54 0 in chilipeppr with the axis travel limit programmed into chilipeppr as well. I just ran a full file and the rapids cut through the work piece, and it could be because it runs into the (+) Z direction rather than (-).

    In Fusion, I do start at 0,0,0 being bottom left corner and extrude down, which should set my G54 at the top face, bottom left corner of my work piece. The gcode file also mirrored the entire part along the x axis so the word “LOVE” was carved upside down (think of the V being /\). I wasn’t sure if that was due to a setting that I screwed up in Chilipeppr/tinyg, wiring, or a mistake I made in Fusion (I’m used to SolidWorks + MasterCAM). When I set G54 0 and hit start, the machine began cutting toward me instead of away from me, as the model was drawn.

    On the bright side, the wiring change and such made it so the Z axis no longer misses steps or moves to an incorrect plane. So that issue seems to be fixed. I plan to add limit/homing switches soon, but I wanted to make sure I at least had it working before doing so.

    I copy/pasted a chunk of the code. The file is 106k lines long, so I just put some of it here. If you want more, I can put the whole file. I cut this down to 4 pages of code.

    https://docs.google.com/document/d/1XssgdBwJcz9nt9ZNdHXydIPs8x7oIxkhn1t6nicIsio/edit?usp=sharing

    Thank you for all the help!

    July 10, 2017 at 10:27 am #10459
    cmcgrath5035
    Moderator

    Have you tried running the rather simple 2D Chilipeppr Logo Gcode on your setup?
    That should be a way to determine if your physical concept of what is +x, +y and +z direction, as set with motor wiring and polarity settings, matches a simple 2d drawing.
    You are using rather sophisticated tool chains that have a lot of flexibility, its difficult to identify what might be off on your design relative to your machine setup.

    I do see in your Gcode a number of codes that are not supported by tinyG, it is difficult to tell if skipping those commands has material effect on how your code runs.
    Here is the tinyG reference:

    July 10, 2017 at 7:52 pm #10460
    Nell
    Member

    So I tried the Chilipeppr Logo and learned a few things…

    1) Z-axis polarity had to be set to CCW, as did the Y axis. X operated just fine.
    2) X+ is to the right when facing the machine front, Y+ is (now) away from the front, and Z+ is away from the surface rather than into.
    3) The 2D GCode file required that I manually plunge the mill into the surface. I dropped it in 1mm as I saw the retract was set to 3mm in the file. I figured that would be sufficient. Prior to setting the Z so that (-) is into the material, it simply carved the air with the retract position actually in the material.
    4) I clearly need more practice with Fusion. For some reason when I load the model in Chilipeppr, the visual render has the origin at the bottom of the stock rather than top. I seem to have inverted something, and I’m not sure what. Live and learn, I suppose.

    I’m using Fusion’s adaptive pocket clearing to do the milling code that you saw. I had it set to post in grbl thinking it would know what could be handled and what couldn’t be. I have looked over the code link and will try to keep my code and toolpaths to ones that the system can handle going forward.

    Is there anything else you can recommend for setup that I might have missed? I tried to follow the setup wiki as best I could, but it seems some nuances may have been lost on me.

    Thank you again, I truly appreciate the help. I’m so close to being able to cut, I can see the finish line.

    Regards,

    Mike

    July 10, 2017 at 9:04 pm #10461
    cmcgrath5035
    Moderator

    There is no magic solution in this space.
    Too many variables and new great ideas.
    Once your have decided on a particular tool chain, e.g. Fusion and Chilipeppr, stick with it a while and develop your understanding of the nuances and what works best.

  • Author
    Posts
Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.