Forum Replies Created
-
AuthorPosts
-
GaylordMember
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.
GaylordMemberIt is in the settings, or you are missing steps due to a slight binding at the end of travel or you are getting noise from somewhere. Can I ask what kind of machine this is, the size of the steppers, are the feed screws acme thread or bearing?
GaylordMemberI am assuming nothing else about the machine has changed. My only advice is to remove all grease and oils from the lead screws and the nuts by using a solvent like acetone. Brush on some acetone while running the axes to get the residue from the nuts. Use a stiff brush and lots of rags to get everything clean. Before lubricating with WD40 run each axis back and forth several times one at a time. Listen to any changes in the sound during travel. try running the program the program. If this works you were probably missing steps. If this doesn’t help try adjusting your acceleration settings.
On my machine, I found when hand turning each axis I could feel binding along the way in different spots. The fix after much frustration was replacing the lead screws with ball screws and more powerful steppers on the X and Y Axes.
GaylordMemberDon’t blame you for your frustration. Despite making significant progress on my own, (trial and error), I have not found a source of support. But I have meticulously documented the travel errors between F360, TinyG and ChilliPepper in inches and mm. A crash dump $$ for different machines would be helpful. But the only ones I have found don’t identify the machine adequately and the settings are critical. I feel the weak link is with TinyG which is where the machine parameters must be set. Having to use several documents thru links with inconsistent instructions, nomenclature and references makes the documentation a PITA. I have virtually written my own yet through careful measurement of the results have found (I believe) a mathematical error in TinyG. (Which could be related to how it interprets post processed files, and inadequate descriptive information in F360.) Challenging is a single setting can cause the file to fail to generate gcode. So if you need to create consistent and a variety of parts there is a lot of work ahead of you. Solution: Spend a lot more money on a great machine.
GaylordMemberThanks for your previous troubleshooting help. I re-created the identical model in F360 after changing the preferences to mm. I did the CAM setup in mm and published the gcode. The simulation worked fine.
I homed the machine, zeroed Z at WCS, work piece top using G92 Z0. I’m using G54.
The machine stops at the same line stat:3 So I did a $sr and got:
posx:76.833,posy:102.443,posz:9.031,vel:23.49
posx:76.522,posy:102.607,posz:9.034,vel:18.84
qr:30
posx:76.313,posy:102.660,posz:9.036,vel:119.69
qr:31
posx:76.151,posy:102.696,posz:9.037,vel:36.07
posx:75.805,posy:102.697,posz:9.040,vel:16.91
posx:75.802,posy:102.697,posz:9.040,vel:0.00,stat:3
qr:32
$sr
$sr
tinyg [mm] err: Bad number format: X76.16 Y99.703 Z8$srYour Thoughts?
April 18, 2017 at 1:22 pm in reply to: PAID HELP required (Central Coast/ Sydney AU- Openbuilds OX,TinyG #10349GaylordMemberMan can I relate to your frustration. So after several attempts I did get my set up working. However I ran into the Fusion 360 post processor issues but only relating to the location of the origin and direction of Z moves.
So First let me say a couple things: (since I’m on the east coast in Maryland)
Draw a simple brick of a part with 1 slot (Pocket) on the top. Nothing fancier than that.
Go to Cam and generate the setup and tool path for the slot only using ALL the automatically generated (default) parameters and the tool from the suggested list that will fit your slot (smaller).
Remove any bit or better yet disconnect or remove your spindle motor. TinyG does not care.
(I’m assuming here that you do have communication set up)
Power up TinyG, wait a moment, press reset button, wait, look for the return text string. Don’t worry about reading anything but the word “ready”
(I’m assuming your using Terminal to send code to TinyG)
I copy and paste the 360 code into a blank text page. Name it 1.
Then I select all in text, copy and paste into the terminal line. (Only some of it will be visible but it is all there)
Be ready to hit the TinyG reset button. Hit send and watch.
Reset send and watch as many times as you need to prove that the motion matches your intention (your drawing) Make a list of everything you suspect or question. Be sure you are viewing from the correct position so that all the X,Y and Z moves are natural and relative to the part origin.
From your list take the first thing that does not seem to be correct. Think about this one move only. Remember if the tool path previewed correctly in 360 and the machine did it wrong it can only be the TinyG or the machine. The machine is stupid and only does exactly what it is told. Find and correct that error.
Always begin this process with the machine at machine home, 0,0,0
If it looks home send $HOME and see if it says 0,0,0. If not fix that first.
There are only two types of HOME. Machine HOME and Offset HOME
During TinyG set up there are persistent and non persistent positions (settings). Know the difference and use the right ones.I did this over and over again until I got it right. Same part, no 360 parameter changes, same pasted text code. This is the machine (actually TinyG settings and machine wiring) wring-out, to get all the bugs, TinyG or hardware, working. I started this and then began re-writing the wiki into a single document set up manual. Because I got my machine working and have been doing other projects I did not finish the manual. But if you or others would like to contribute to my time I would consider finishing it. I can’t do much more than the above for you because I have to go earn some groceries. Good luck I hope this helps.
GaylordMemberSort of related…I have set up a 3040CNC with a TinyG V8 controller. I use Fusion360 for design. TinyG/Wiki suggested the Z axis limit be installed at the top of travel (Z0). This means all Z moves need to be – (Negative). F360’s post processor commands are all + (Positive). I’m guessing that the top of the work piece needs to be registered, but there doesn’t seem to be any instruction on the best way to do this. Creating the set up and cutting paths appears to work okay. And I did set Z0 to the work piece. But Z just skims over the surface, right path but no cutting. What am I missing? Can someone help me please. Thank you in advance.
GaylordMemberHas there ever been an answer for the original question? Using Mach3 with Tinyg?
-
AuthorPosts