Invalid posx/posy response at start of G03 operation

Home Forums TinyG TinyG Support Invalid posx/posy response at start of G03 operation

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #12186
    jimtellier
    Member

    So I’ve searched a lot for info on “invalid sr: responses” and such, but coming up blank. I have a Very simple case where I’m doing the following:
    (after Homing X,Y,Z):
    G90
    G01 X100.0 F300
    G01 Y50.0
    G01 X150.0
    G03 X180.0 Y20.0 R30 F200
    ———-
    The responses after the G03 was sent are here:
    {“r”:{},”f”:[1,0,22,102]}
    {“sr”:{“posx”:180.000,”posy”:20.000,”feed”:200.00}} <<<<<<<<==== THIS!?
    {“sr”:{“posx”:150.005,”posy”:49.798,”vel”:149.23,”stat”:5}}
    {“sr”:{“posx”:150.026,”posy”:49.012,”vel”:199.93}}
    {“sr”:{“posx”:150.041,”posy”:48.451,”vel”:38.78}}
    {“sr”:{“posx”:150.043,”posy”:48.406,”vel”:38.78}}
    {“sr”:{“posx”:150.088,”posy”:47.834,”vel”:199.93}}
    {“sr”:{“posx”:150.152,”posy”:47.028,”vel”:200.00}}
    {“sr”:{“posx”:150.248,”posy”:46.225}}
    {“sr”:{“posx”:150.356,”posy”:45.405}}
    {“sr”:{“posx”:150.499,”posy”:44.608}}
    {“sr”:{“posx”:150.646,”posy”:43.812}}
    {“sr”:{“posx”:150.837,”posy”:43.007}}
    {“sr”:{“posx”:151.027,”posy”:42.220}}
    {“sr”:{“posx”:151.257,”posy”:41.443}}
    {“sr”:{“posx”:151.496,”posy”:40.652,”vel”:200.00}}
    {“sr”:{“posx”:151.767,”posy”:39.888}}
    {“sr”:{“posx”:152.043,”posy”:39.127,”vel”:200.00}}
    {“sr”:{“posx”:152.360,”posy”:38.363}}
    {“sr”:{“posx”:152.679,”posy”:37.619}}
    {“sr”:{“posx”:153.027,”posy”:36.888}}
    {“sr”:{“posx”:153.396,”posy”:36.148,”vel”:200.00}}
    {“sr”:{“posx”:153.783,”posy”:35.436}}
    {“sr”:{“posx”:154.183,”posy”:34.732,”vel”:200.00}}
    {“sr”:{“posx”:154.607,”posy”:34.042}}
    {“sr”:{“posx”:155.055,”posy”:33.347,”vel”:200.00}}
    {“sr”:{“posx”:155.514,”posy”:32.680}}
    {“sr”:{“posx”:155.991,”posy”:32.025,”vel”:200.00}}
    {“sr”:{“posx”:156.495,”posy”:31.370}}
    {“sr”:{“posx”:157.008,”posy”:30.743,”vel”:200.00}}
    {“sr”:{“posx”:157.534,”posy”:30.127}}
    {“sr”:{“posx”:158.093,”posy”:29.518}}
    {“sr”:{“posx”:158.650,”posy”:28.931}}
    {“sr”:{“posx”:159.231,”posy”:28.366}}
    {“sr”:{“posx”:159.830,”posy”:27.797}}
    {“sr”:{“posx”:160.442,”posy”:27.265}}
    {“sr”:{“posx”:161.058,”posy”:26.739}}
    {“sr”:{“posx”:161.711,”posy”:26.233,”vel”:200.00}}
    {“sr”:{“posx”:162.354,”posy”:25.740}}
    {“sr”:{“posx”:163.020,”posy”:25.280,”vel”:200.00}}
    {“sr”:{“posx”:163.703,”posy”:24.814}}
    {“sr”:{“posx”:164.394,”posy”:24.391}}
    {“sr”:{“posx”:165.087,”posy”:23.972,”vel”:200.00}}
    {“sr”:{“posx”:165.799,”posy”:23.585}}
    {“sr”:{“posx”:166.530,”posy”:23.199,”vel”:200.00}}
    {“sr”:{“posx”:167.261,”posy”:22.850}}
    {“sr”:{“posx”:167.996,”posy”:22.511,”vel”:200.00}}
    {“sr”:{“posx”:168.760,”posy”:22.195}}
    {“sr”:{“posx”:169.514,”posy”:21.899,”vel”:200.00}}
    {“sr”:{“posx”:170.277,”posy”:21.628}}
    {“sr”:{“posx”:171.062,”posy”:21.370}}
    {“sr”:{“posx”:171.839,”posy”:21.140}}
    {“sr”:{“posx”:172.621,”posy”:20.930}}
    {“sr”:{“posx”:173.426,”posy”:20.737}}
    {“sr”:{“posx”:174.218,”posy”:20.571}}
    {“sr”:{“posx”:175.014,”posy”:20.424}}
    {“sr”:{“posx”:175.831,”posy”:20.300,”vel”:200.00}}
    {“sr”:{“posx”:176.634,”posy”:20.195}}
    {“sr”:{“posx”:177.441,”posy”:20.119,”vel”:200.00}}
    {“sr”:{“posx”:178.265,”posy”:20.054}}
    {“sr”:{“posx”:179.071,”posy”:20.024}}
    {“sr”:{“posx”:179.833,”posy”:20.004,”vel”:136.06}}
    {“sr”:{“posx”:180.000,”posy”:20.000,”vel”:0.00,”stat”:3}}
    ———
    As I’m using these responses to draw a 3D visual of the toolpath, what I see is obviously wrong: a straight line from X=150, Y=50 to X=180, Y=20…. Followed by the (correct) ARC from/to the same coordinates.
    Why is this “extra” prefixed “sr:” response being generated?
    If this isn’t a bug, how can I prevent it?
    If it Is a bug, how would I work around it?
    Thanks for any assist or ideas anyone may have!
    Jim

    #12187
    Gaylord
    Member

    If you’re not using motors with feedback the controller is probably losing sync, missing steps, etc. Here is my take:
    Analyzing the provided G-code and the corresponding responses, it appears that there are no errors in the execution of the code as given. Let’s break down the G-code and check the responses:

    1. **G90** – Sets the machine to absolute positioning mode.
    2. **G01 X100.0 F300** – Moves the X-axis to 100.0 units at a feed rate of 300.
    3. **G01 Y50.0** – Moves the Y-axis to 50.0 units (keeping the last set feed rate of 300 since none is specified here).
    4. **G01 X150.0** – Moves the X-axis to 150.0 units.
    5. **G03 X180.0 Y20.0 R30 F200** – Executes a clockwise arc move to (X180.0, Y20.0) with a radius of 30 units at a feed rate of 200.

    From the responses you provided, here are some observations:
    – The initial feedback from the machine after the G03 command {"r":{},"f":[1,0,22,102]} suggests that the command was accepted without any functional errors.
    – The sequence of status reports ({"sr":{...}}) confirms that the machine successfully completed the arc to the endpoint (X180.0, Y20.0) at the set feed rate, transitioning from the previous X and Y positions and gradually decelerating to a stop as it reaches the target position.

    The {"sr":{...}} status reports provide real-time updates of the machine’s position and velocity during the operation, and they indicate a normal execution of the arc command with the machine gradually reducing speed as it approaches the final position, and finally stopping with {"vel":0.00,"stat":3} which suggests that the machine has completed the motion and is now idle.

    Based on this information, there does not appear to be any errors in the G-code or its execution as per the machine responses. If you were experiencing issues or discrepancies in the actual movement or outcome of the machine operation, it would be essential to check the machine setup, calibration, and perhaps mechanical elements like backlash or rigidity which could influence the precision but are not reflected in the G-code itself. Based on your description of seeing a straight line from (X=150, Y=50) to (X=180, Y=20) followed by the correct arc, it seems there might be an interpretation or execution issue with the G03 command in the controller or its software.

    Here are a few thoughts on what might be happening and how to address it:

    1. **Buffering or Execution Delay**: The first response showing a straight move might be due to how the controller buffers and processes the G-code commands. Some controllers might pre-calculate or anticipate the endpoint of a movement before executing the path, leading to this initial “direct line” reading.

    2. **Controller Software or Firmware**: Ensure that your controller’s software or firmware is up to date. Sometimes, bugs or peculiarities in how G-code commands, especially complex ones like arcs, are interpreted can be resolved with updates.

    3. **G-code Parsing and Visualization Software**: The tool or software you use to visualize the toolpath might be misinterpreting the responses from the controller. Verify that the software correctly handles the G-code and controller responses, particularly for arc commands.

    ### Prevention and Workaround:

    – **Add a Dwell Command**: Sometimes, adding a small dwell (pause) before complex commands like arcs can help stabilize the motion and give the controller time to process the correct toolpath. You might add a G04 (dwell) command with a short pause, like G04 P0.1 (for a 0.1-second pause), right before the G03 command.

    – **Explicit Path Commands**: Another approach might be to break down complex movements into simpler steps that the controller might handle more predictably. Although this isn’t ideal for arcs, it could be a practical short-term workaround.

    – **Check and Reset Modal States**: Ensure no modal state from previous commands adversely influences the arc command. For instance, explicitly resetting certain modes or ensuring no conflicting modal commands are active before the arc might help.

    – **Consult Documentation/Support**: Check the controller’s documentation for any known issues with arc commands or similar scenarios. Consulting with the support team or forums where users discuss the same controller might also offer insights or solutions.

    – **Software Update/Firmware**: If it turns out to be a bug with the firmware or controller software, an update or patch from the manufacturer might be necessary. If no update is available, contacting support with detailed information (like the one you have) can push for a resolution.

    These suggestions aim to stabilize the toolpath visualization and ensure that what you simulate or visualize closely matches what the machine is programmed to do. If the issue persists, it might be necessary to delve deeper into the controller’s settings or even consider alternative controllers if this is a recurring or unresolvable issue with your current setup.

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