I have been digging into the generated gcode that WAM puts out, trying to track down issues with my cut and I am wondering if anyone can give me an explanation on why you generate your gcode as you do?
It is a very, very simple gcode, all works on a point to point basis, can not do arcs, and for some reason calls up a new point every 5mm instead of just using the start and end points of a line. This causes issues like axis wander in your code.
You also have random feed changes in the middle of straight lines, why? I’ll post some screen shots to help explain.
You can see my X coordinates start to wonder a bit, not by much but enough to cause concern on the overall quality of your generated gcode. This part is a rectangle with straight lines, set up with zero rotation (posted this part multiple times to make sure it wasn’t rotated in WAM). You can also see in the middle of my straight line, we jump up 5mm/min in our feed rate, why? I understand slowing down at the corners and speeding up after them, but that’s not at all what’s happening here.
I’m not sure it’s the same thing because we haven’t had it happen with rotation/drifting before, but we’ve noticed if you scale your drawing in wam and you’ve already input your positioning coordinates before you scale it will show your coordinates as the coordinates that you input but can slightly shift them. We realized when we were cutting lines at X=0 and Y=0 and we scaled our overall drawing and our cut got moved to x=0.79 (noticed it on the cut and then looked back at the gcode to see this). In order to prevent this, you have to reset your coordinates AFTER you scale it even though it says the coordinates are correct.
Again, not sure if this is what you’re experiencing but we’ve found the scaling feature can mess up your cuts. Did you scale it at all?
I am wondering if the speed change aligns when the waterjet starts collecting abrasive. Maybe it slows down to make sure there’s enough abrasive in the cut?
These are some good observations and I would love to dive a bit deeper! In order to make sure we are looking at the same issue and able to re-create it, please share the gcode file and DXF (or SVG) file used to import into WAM!
Through my findings, the axis wander doesnt happen on the inside profile of my parts, but will always happen on the outside profile. It is not consistent from part to part, some will have wander on all 4 edges, some will only have it happening on 3 out of the 4 (like the one I just shared).
I do not do any scaling in WAM, all adjustments are done in SolidWorks and then the dxf is remade with updated part if I need to change anything. Good to know scaling is an issue though.
@alindberg That’s a good thought on abrasion collection, I would love some clarification on this. I don’t see any lines calling for any pinch valves being opened or anything so I am not sure how they control that system yet, seems like they do a lot off of just timers, but I haven’t had time to dig into that yet.
Still finding issues with my cuts. I have added the WAM generated gcode, the dxf file and some pictures of the issues being seen on the cut part.
The axis wander that I called out last post is still happening in the code, the wander is only happening on the edges of my part that do not show any issues, and the wandering axis stuff still only happens on the outside profile of the part.
Measurements of the finished part seems to suggest that the machine gets out of position for some reason and corrects it self at a random time. You can see that the machine over cut along the x axis and corrected itself to come back to the correct dimensions just before the last section of the cut.
After reviewing more code for different shaped parts, I don’t believe the feed change in the middle of my lines are for abrasion collection, but that is still unclear. I believe they would be more consistent and happen more often than what I am seeing, but would love more info on this. Sometimes this feed change happens over a 5mm stretch, sometimes it happens over a 10-15mm stretch.
In the attached pictures, the part you see is in the same orientation as it was during the cut. The green bracket area measures out to be .002" off expected dimensions, and the red bracket area measures out to be .028" over expected dimension.
The pierce narks you see are not an issue. I am only talking about the right and left side of the part. On the right side you can see the issue about half way up the edge. On the left side you can see the issue appear in the top left corner, although much less of a correction.
Thanks for sharing the files for a deeper look! I found the following when using gcode files generated with the Diffuser DXF you provided:
Center-line Cut Path
The internal rectangle was straight edge on all 4 sides
The external rectangle was straight edge on all 4 sides
Outside Cut Path
The internal rectangle was straight edge on all 4 sides
The external rectangle shifted on the right x-axis from 253.48mm to 263.50mm. This is a +0.02mm change.
The external rectangle did not shift on the y-axis as it moved across the bottom straight edge.
The external rectangle shifted on the left x-axis from 112.17mm to 112.15mm. This matches the right side by -0.02mm.
The external rectangle shifted on the top y-axis from 36.50 to 36.48mm. This is a -0.02mm change.
It is strange to see the very minuscule changes of 0.02mm from 3 of the 4 sides, especially on the external and not the internal. Perhaps it has something to do with the DXF file’s angles on those 3 corners, however we could not find anything within the QCAD software when looking into it.
I then tried to re-create the issue by creating similar size rectangles within each other and generating a new DXF. After inspecting the gcode, both the internal and external rectangles had all 4 (8) straight edges. Perhaps there is something within the diffuser DXF file causing a 0.02mm skew?
I am personally not sure why that is or what the root cause could be - I will share this information with the internal dev. team to help investigate or understand a bit further but being not able to re-create it consistently makes it difficult to discern the root cause.
The 0.02mm drift should barely be noticeable - if at all. The issue highlighted in your picture is a sign that there may be some loose hardware resulting in the large x-axis shift. The first thing that comes to mind are the set screws that hold the x-axis motor within the gantry/carriage.
Remove a bellow cover by lifting up and pulling it away.
Remove the limit switch (2x screws on the left and right with a Philips screw driver). Disconnect the wire and remember the orientation of the limit switch when re-installing. (Taking a picture before removing works best for me)
Remove the plastic bellow holder. (2x screws on the top and bottom with a 2.5mm hex)
The 2x set screws can be seen threaded into the body of the x-axis motor. Tighten both screws up with a 2.5mm hex.
Re-install this side and repeat on the other side of the x-axis motor.
Do you find that any of the x-axis set screws were loose?
Okay, so here is what I think is happening. I believe the drawings you export from SolidWorks either contain rounding errors, or the WAM software is interpreting them as less than perfectly vertical/horizontal lines.
The .002" difference is simply the limit of the gantry systems stepper motors - from the tech specs on the main website, the gantry positional accuracy is only .003"(.08mm), which is likely one step in the motor. (I could be wrong.)
In the g-code, we see a drift ~.02mm - the system can’t do that small a movement, and it eventually forces the gantry to make one step. That step is the jogs you see on your parts.
I don’t know if you’re the only one suffering from this, but appears you’re the only one talking about it. It might be something with your SolidWorks export settings.
The only solution I have is to check your SW settings. The band-aid solution is to check all the g-code you generate to make sure all the outside edges are square. Tedious.
We use SW ourselves and haven’t encountered this issue, but we only have like ~10 hours of cut time so far. We also cut much smaller parts, and this drift may only occur on longercut lengths.
@Alex Just finished checking both sides of the x axis motor and did not find any loose hardware. I do not believe it has anything to do with the DXF file in question because I have cut multiple files that have this similar rectangular profile but different sizes and I see the code drift happening in almost all of them, and like you said, I do not think that is what’s causing the big issue we see here on my part, but it is something that shouldn’t be happening and at this point I’m double checking all aspects. I would also like to understand the reasoning for 5mm segments being called out instead of using a simpler point to point code output like the more advanced machines do. If your machine can go from 0mm to 5mm, why not just tell it to go from 0mm to 35mm or whatever your ending point ends up being? All the code wander we see wouldn’t even be in question at that point.
Anywhere else you’d like me to check? Was going to check y axis but I suspect they are located in the rear of the machine which is a pain in the ass to access so I want to double check before digging around.
@agk8624 Thanks for the input. I have just checked into the export settings and do not see anything that would indicate it would have any rounding errors or anything so if you have a certain setting you think could be causing it, please point me in the right direction. I do seem to be the only one talking about it, but they also do not like people poking around and modifying their own machine so I’m sure a lot of people don’t dig around as much, but based on how many complaints their software has, I wouldn’t be surprised if other people have the same code wander and just don’t know about it. Like I said above, I don’t think this is the reason I am seeing these steps in my part, but it certainly could be pointing to an issue, everything is suspect at this point.
I have edited the gcode WAM has output and I have corrected the code wander on a few cuts to test it out and I still see the steps in those parts as well. These steps do not occur on every part either. So far I cannot seem to find a pattern to the issue, seems random at the moment but still trying to nail that down.
Not sure I will ever get any clarification on the gcode output so I decided to try some stuff out myself and see what works. Had some spare time today so I took a WAM generated gcode file and slimmed it down to only the necessary steps. Instead of using a 5mm point to point system, I just simplified it and took out all the steps between my lines starting point and ending point.
I also removed all the random feed changes you see in the WAM generated code because there seems to be no reason for them, but if anyone with actual knowledge of the WAM generated code thinks different, I would love to hear it.
As to be expected, this part turned out just fine with no issues and a much smaller file size (not that file size has been a problem yet). Part came out without any issues on the cut surfaces, and the machine behaved just as you would expect. So why does WAM generate code the way it does?
I have also taken this opportunity to play around with the config file as well and it works. The very last line of the most up to date config file is the value to change when you want to adjust your new origin setting. By default, this value is set to 10, that means when you set your z height AND your new origin in the cut setup, you will only be able to move in 10mm increments. If you want a more precise origin setting at the machine, change this value down to a lower number. I have not tried any decimals yet, but my whole number adjustments have worked.
I have added my quick test cut, just a 3x2 rectangle with a 2x1 rectangle inside. You can see the DXF file I used, as well as the WAM generated gcode, and my hand edited gcode.
Figured I would add a quick screenshot of the two edits so people who can not open gcode files to view. The entire parts code is shown in the hand edit and in the WAM generated code, we barely get through the inside profile in the visible code.
You can also see 8 feed changes in the WAM code, still trying to figure out why.
