Re: [Emc-users] Code interpretation in EMC
Thomas wrote : I think possibly for many EMC users, CAM is not an easy thing. Many plasma applications are using artistically oriented patterns and programs, such as clipart or truetype font cutouts and without a decent CAM, offset functionality can be a huge advantage. One could argue that offset functionality is a CAM issue altogether, but fortunately, there is a G-code for it :) dave wrote: Synergy (www.webersys.com) takes an interesting approach; it will cut into the corner as far as it can w/o gouging. Then you either use a smaller cutter or the corner routine with a smaller cutter to appropriately clean out the corners. gcode plugin for inkscape do things like this also. For those like thomas said that uses EMC for artistically oriented cuts, where precision in not really important, could be a simple solution. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
Hello, Dave! Thank You for Your insight! I totally agree that I should concentrate on the cad/cam process so that I eliminate the cause of the issue instead of fighting consequences... The thing is that I have to complete this pretty large order very quickly, so I thought that I could quickly resolve it in EMC. Seems like I will have to do it over again in the cam application, so it is going to be all-right. Out of curiosity and half-professional interest I would like to ask You to share some basic details about that waterjet machine that is running EMC. I have never heard about EMC on waterjet machines and I thought that I might be the first one doing this, but it turns out that it is not true :) Can You tell me, who originally produced that machine, how old is it and what is it's working envelope size? And is it 3 axis or 5 axis machine? Thank You in advance! Viesturs 2010/8/19 Dave e...@dc9.tzo.com: Viesturs, I think you need to work on the Cad to Cam to Gcode process. I put EMC2 on a production waterjet machine in June and it has been buzzing along happily ever since. I had to convert about 80 existing Gcode programs so EMC2 could run the code and I was amazed at some of the poor quality Gcode they had been running, so I re-created many DXF files from Gcode via a DXF to Gcode converter program, put the DXFs into Autocad and then cleaned up heavily segmented dxfs by using fitted arcs. I used Sheetcam to create the Gcode and that worked out very nicely. Sheetcam has a definite learning curve but it is worth it. I couldn't find anything that worked as well as Sheetcam for the waterjet. Lousy Gcode will drive you nuts no matter how smart EMC2 becomes. Dave (Dave911 on the IRC) On 8/19/2010 1:41 PM, Viesturs Lācis wrote: 2010/8/19 Chris Radekch...@timeguy.com: Let me try to explain an example. I really think the disconnect between how I as a programmer think about it and how a user thinks about it is our different understanding of what a corner is. I tried to explain this in my last message. Say you are cutting inside a bunch of square pockets. If you use a reasonable tool size for it the offset path is some smaller squares. If you use a larger tool diameter, the offset path gets smaller. At some point, as you keep enlarging the tool, when the diameter of the tool is larger than the side of the square, the offset path disappears (it becomes a square with NEGATIVE side length). At this point EMC will give you an error because it can't make the tool follow inside that path anymore. Note EMC doesn't know these pockets are squares. But when it calculates these endpoints generated by finding where the tool fits inside the corner, and sees that they are connected by degenerate lines, it errors. (EMC considers two corners at a time because you need to know two endpoints to make a compensated move. These corners are defined by the three nearby moves. This is the extent of its knowledge of your programmed motions as it moves along.) I understand you want it to keep going in some cases of degenerate paths, and I do too. But without knowing things it can't know (like conceptually what the part looks like) it can't keep going without guessing. In your program that cuts a hundred square pockets, what does it mean to keep going if the tool doesn't fit in them? I think that I understand the explanation of programmer's point of view very well. So I have a question - how difficult is it to achieve following behavior: skip those lines of code in concave corner, which are smaller than tool, and continue, if there is any other G0 or G1/G2/G3 code to be executed. In Your example all the square pockets would be skipped and outside contour would be cut. In my example I would get, what I want. My idea, how to achieve this, is : 2010/8/19 Chris Radekch...@timeguy.com: You are right - EMC does have handling for concave corners. When two moves come together to form a concave corner, EMC calculates where the tool is tangent to both original moves and puts the offset corner there. If 1) tool is in situation, where it is a tangent to 2 lines - one, that has just been executed and the other - one that has not yet be done and 2) that second tangent line is not the next line in the queue then skip all the remaining G1/G2/G3 lines so that the line, which is tangent of the tool and which is not yet executed, is next in the queue and execution of the code is resumed from there. How hard is that from programmer's point of view? This would solve my problem that code consists of very small straight moves. I know that using some other CAM programm would solve the cause of the issue rather than trying to workaround the consequences like I am trying now... I understand that there might be other commands beside G1/G2/G3 and other special cases... Viesturs --
Re: [Emc-users] Code interpretation in EMC
Chris Radek wrote: On Thu, Aug 19, 2010 at 06:06:58PM +0200, yann jautard wrote: Did you use G64 Ptolerance when using G41/42 to cut a corner ? This could explain why it did not produced an error. This is unrelated. ok, sorry, I must learn to shut my damn mouth when I do not know things :/ As I read the rest of explanation, I understand very well why this is unrelated. But as Stuart suggests : It seems to me that just having a configuration option somewhere, or a register, or a parameter, or a menu choice somewhere - such as whether to treat the condition as an error, warning, or silent, and knowing the result - would help to solve the desired unknown. For myself, in most situations it would be very convenient to just follow the path and leave what it cannot reach, Why cant be something that is used like the G64 ? I mean defining a tolerance on the part corners, not oriented to keep the cutting speed but to keep the path runing in those cases where a point is unreachable due to the tool diameter. Well I see a case where this can't work without needing a bit more intelligence : http://imagebin.ca/view/htk7AZmT.html Here this should work for the green zone, but the red one will never be reached without a bit of complicated thinking. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
Unfortunately a lot of CAM software doesn't do a great job of producing Gcode. I was working with some very high end graphics art software used to make vinyl sign graphics and the Gcode code that they were outputting was simply horrendous. When I asked why they were outputting line segments in the .001 to .003 inch range they had no apologies..and felt to need to change it. Some complicated sign cutouts would have more than 250,000 lines of gcode. Their solution was for me to create a filter program to remove the short segments with fitted arcs! They didn't think they needed to fix their short segment issues since technically when the Gcode was run on a machine - slowly - the product created was correct as far as they were concerned. Their software was priced over $25,000 per copy! Crazy. That was the end of that project. The water jet machine I retrofitted was a Jet Edge 3 axis waterjet which was about 15 years old. The original controls had been replaced 10 years ago with an Allen Bradley 9 series control and when that began to fail we got the job of replacing the AB controls with EMC2.The machine is fed automatically via a conveyor. The machine bed is actually a stainless steel chain conveyor so after the machine is done cutting, the chain conveyor moves the entire cut up sheet out of the waterjet to a downstream belt conveyor where the parts are removed from the scrap. A new, un-cut sheet is conveyed into place and the machine automatically begins cutting the new sheet. They love EMC2. It runs faster than the AB 9 series and has the huge advantage of being PC based. I replaced the existing AB servo drives with Automation Direct 1 KW brushless motors and drives. We also replaced the ball screws and linear rails. The control cabinet was gutted and all of the components were replaced.All of the machine wiring on the frame was also replaced. Other than the frame, the pump, and the carriage assembly, the machine is essentially all new. It was an expensive retrofit but the customer has a virtually new machine now for less than 1/2 the price of a new replacement. The customer is now considering having us put together two more waterjet machines from scratch. Using EMC2 for the CNC control and using Jet Edge for the water pump system and water components. The Jet Edge pump system is very robust. The machine bed is about 5 feet x 9 feet in size but the machine has 4 water jet nozzles on the carriage so it cuts 4 parts at once. This is a high speed machine since it cuts softer materials like semi-rigid foam and they run very fine water jets in the .0005 inch range.The cuts are extremely fine and look like they were made with a knife.The machine cuts at speeds up to 1200 ipm on thinner materials. Dave (Dave911 on the IRC) They expected the CNC system to On 8/20/2010 3:41 AM, Viesturs Lācis wrote: Hello, Dave! Thank You for Your insight! I totally agree that I should concentrate on the cad/cam process so that I eliminate the cause of the issue instead of fighting consequences... The thing is that I have to complete this pretty large order very quickly, so I thought that I could quickly resolve it in EMC. Seems like I will have to do it over again in the cam application, so it is going to be all-right. Out of curiosity and half-professional interest I would like to ask You to share some basic details about that waterjet machine that is running EMC. I have never heard about EMC on waterjet machines and I thought that I might be the first one doing this, but it turns out that it is not true :) Can You tell me, who originally produced that machine, how old is it and what is it's working envelope size? And is it 3 axis or 5 axis machine? Thank You in advance! Viesturs 2010/8/19 Davee...@dc9.tzo.com: Viesturs, I think you need to work on the Cad to Cam to Gcode process. I put EMC2 on a production waterjet machine in June and it has been buzzing along happily ever since. I had to convert about 80 existing Gcode programs so EMC2 could run the code and I was amazed at some of the poor quality Gcode they had been running, so I re-created many DXF files from Gcode via a DXF to Gcode converter program, put the DXFs into Autocad and then cleaned up heavily segmented dxfs by using fitted arcs. I used Sheetcam to create the Gcode and that worked out very nicely. Sheetcam has a definite learning curve but it is worth it. I couldn't find anything that worked as well as Sheetcam for the waterjet. Lousy Gcode will drive you nuts no matter how smart EMC2 becomes. Dave (Dave911 on the IRC) On 8/19/2010 1:41 PM, Viesturs Lācis wrote: 2010/8/19 Chris Radekch...@timeguy.com: Let me try to explain an example. I really think the disconnect between how I as a programmer think about it and how a user thinks about it is our different understanding of what a corner is. I tried to
Re: [Emc-users] Code interpretation in EMC
On Thu, Aug 19, 2010 at 07:54:36AM -0500, Viesturs L??cis wrote: I just received also this error message: Straight feed in concave corner cannot be reached by the tool without gouging It indicated that the error is around line 24, so here is the part of the code: G1 X+167.031 Y+46.741 G1 X+167.643 Y+46.983 G1 X+168.223 Y+47.330 G1 X+168.364 Y+47.433 G1 X+168.364 Y+23.726--line24 G1 X+147.289 Y+23.726 G1 X+147.289 Y+54.982 The code consists of very small G1 moves. Unfortunately the CAD drawing consisted almost only of splines, which are not very welcome by my CAM application, so it converted the splines in very small straight segments. That is why that file consists of 16344 lines, so I do not see an option of manual correction of the code. Can anyone explain, what is that EMC does not like about the g-code and what can I do to correct it? Yes, the problem is just what the error message says. There is a move that makes a concave corner but the move cannot be reached (the tool cannot move alongside it as you request) without gouging into the profile of the part. Here is a screenshot showing the situation. I copied your code, added g21 and g42 commands, and put a 1.1mm tool in my tool table. I jogged the tool near the corner so you can see the situtation. The highlighted cyan line is from line 7 in my program. The error message points to line 8 in my program, which was your line24. (Notice I used block delete to allow myself to view the unoffset path.) http://timeguy.com/cradek-files/emc/viesturs-error.png Also notice that if line 8 had gone in another direction (say upward), line 7 could have been reached just fine. This is why line 7 isn't the error; it is the whole situation which causes the error and the situation is finalized when line 8 is reached. The harder question you ask is what you can do to correct it. I don't know the answer to that except to say that you must generate gcode that does not have these unreachable moves if you need to use cutter compensation. I did not check your first program with the arc problem because you did not give enough surrounding lines for me to be sure that I would see the same problem. As you can see above, the directions of surrounding moves are relevant when the path is compensated. If you do a similar examination I think you will be able to see the problem. If not, post a screenshot or a complete (but minimal) program showing the problem and I will try to help. Chris -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
On Thu, Aug 19, 2010 at 8:22 AM, Chris Radek ch...@timeguy.com wrote: On Thu, Aug 19, 2010 at 07:54:36AM -0500, Viesturs L??cis wrote: Yes, the problem is just what the error message says. There is a move that makes a concave corner but the move cannot be reached (the tool cannot move alongside it as you request) without gouging into the profile of the part. Here is a screenshot showing the situation. I How does EMC know the profile of the part? -- dos centavos -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
On Thu, Aug 19, 2010 at 08:32:49AM -0500, Stuart Stevenson wrote: On Thu, Aug 19, 2010 at 8:22 AM, Chris Radek ch...@timeguy.com wrote: On Thu, Aug 19, 2010 at 07:54:36AM -0500, Viesturs L??cis wrote: Yes, the problem is just what the error message says. There is a move that makes a concave corner but the move cannot be reached (the tool cannot move alongside it as you request) without gouging into the profile of the part. Here is a screenshot showing the situation. I How does EMC know the profile of the part? Well that terminology might be a tiny bit sloppy. When you use cutter compensation you program a path and you tell EMC to move the tool alongside it. Often this programmed path is the desired part profile, but sometimes it is not. But the concept is the same. (for others following along, here's the screen shot again - path is programmed left to right then down) http://timeguy.com/cradek-files/emc/viesturs-error.png The problem in this case: If EMC were to move the tool *anywhere* along the right side of the highlighted line in that screenshot (as you requested by programming G42 and then that line), the tool would already be at least partly on the LEFT side of the following line. This conflicts with your request to move the tool along the RIGHT side of the following line. I decided to call this gouging partly because this is what EMC1 called a similar situation. But to be very precise, it doesn't necessarily gouge the desired part profile (which only the gcode programmer knows in his own head or napkin sketch). Chris -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
2010/8/19 Chris Radek ch...@timeguy.com: Yes, the problem is just what the error message says. There is a move that makes a concave corner but the move cannot be reached (the tool cannot move alongside it as you request) without gouging into the profile of the part. Here is a screenshot showing the situation. I copied your code, added g21 and g42 commands, and put a 1.1mm tool in my tool table. I jogged the tool near the corner so you can see the situtation. The highlighted cyan line is from line 7 in my program. The error message points to line 8 in my program, which was your line24. (Notice I used block delete to allow myself to view the unoffset path.) http://timeguy.com/cradek-files/emc/viesturs-error.png Also notice that if line 8 had gone in another direction (say upward), line 7 could have been reached just fine. This is why line 7 isn't the error; it is the whole situation which causes the error and the situation is finalized when line 8 is reached. The harder question you ask is what you can do to correct it. I don't know the answer to that except to say that you must generate gcode that does not have these unreachable moves if you need to use cutter compensation. Ok, thank You for the explanation, I kind of realised that it is the case that there is corner that cannot be completely reached, because tool is too big. The way I see the ideal solution - display the error message so that I am warned about the situation, and continue with the code. Using Your screenshot - the displayed tool position would be the point, where tool should do the corner - stop and start moving downwards. That is the desired behavior in current situation. If I will have my CAM programm including the kerf size compensation in the code, it would produce this exact behavior - reach the corner as far as it can bu not moving over the next line (that would be the next line downwards in the screenshot) and then moving on... But I would like not to include compensation in the code so that I can manually tweak it, if I need it and that is why I like the G41/G42 commands as they do all the job. Is there a way to tell EMC that such a concaved corners are acceptable and EMC should move on? I think that plasma and laser tables also might be affected by this situation. I did not check your first program with the arc problem because you did not give enough surrounding lines for me to be sure that I would see the same problem. As you can see above, the directions of surrounding moves are relevant when the path is compensated. If you do a similar examination I think you will be able to see the problem. If not, post a screenshot or a complete (but minimal) program showing the problem and I will try to help. Here is the whole G01/G02/G03 block with all the intro and outro lines. The trickiest part is that error is created in place, where tool has to move on the outer side of the turn (it has to do G02 move, when G41 is active). Another trick is that the part is symmetrical, but EMC does not like only one side, the other one is ok. G64 P 0.05 G90 M6 T1 F300 G0 X+75.917 Y+107.778 G41 M3 S100 M8 G4 P1.5 G3 X+76.064 Y+110.967 I+0.074 J+1.594 G3 X+40.813 Y+96.146 I-2.052 J-44.453 G2 X+38.415 Y+96.146 I-1.199 J+1.920 G1 X+33.000 Y+99.029 G3 X+26.819 Y+97.579 I-2.209 J-4.486 G3 X+27.052 Y+35.097 I+47.193 J-31.065 G3 X+28.022 Y+34.583 I+1.074 J+0.853 G1 X+39.928 Y+34.583 G2 X+45.159 Y+32.636 I+0.000 J-8.000 G3 X+59.223 Y+24.543 I+28.844 J+33.863 G2 X+60.512 Y+22.807 I-0.713 J-1.877 --- my EMC version does not like this line. If I delete it, code is accepted G1 X+60.512 Y+17.516 G1 X+62.013 Y+16.014 G1 X+85.989 Y+16.014 G1 X+87.512 Y+17.516 G1 X+87.512 Y+22.807 G2 X+88.802 Y+24.543 I+2.003 J-0.140 G3 X+102.865 Y+32.636 I-14.789 J+41.970 G2 X+108.096 Y+34.583 I+5.231 J-6.053 G1 X+120.002 Y+34.583 G3 X+120.972 Y+35.097 I-0.104 J+1.367 G3 X+121.206 Y+97.579 I-46.960 J+31.417 G3 X+115.024 Y+99.029 I-3.973 J-3.036 G1 X+109.609 Y+96.146 G2 X+107.211 Y+96.146 I-1.199 J+1.920 G3 X+76.064 Y+110.967 I-33.199 J-29.632 G3 X+75.019 Y+110.640 I-0.074 J-1.598 M5 M9 G40 M2 -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
Chris, Sorry for the catty remark it's just that we have had several conversations about cutter compensation routines. :) thanks Stuart -- dos centavos -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
On Thu, Aug 19, 2010 at 09:31:42AM -0500, Viesturs L??cis wrote: Ok, thank You for the explanation, I kind of realised that it is the case that there is corner that cannot be completely reached, because tool is too big. The way I see the ideal solution - display the error message so that I am warned about the situation, and continue with the code. Using Your screenshot - the displayed tool position would be the point, where tool should do the corner - stop and start moving downwards. That is the desired behavior in current situation. Yes I agree the ideal solution is to know what the *desired* behavior is and then do it - however there are two problems with that - knowing what the desired behavior is - and then doing it. I don't mean to be flippant, but both are very hard. Like Stuart S implied with his question, you don't actually program a part profile in gcode. EMC doesn't know anything about the shape of your desired part. It simply has a series of lines and arcs. It moves the tool along this path, or along the right or left of it. If you tell it to move the tool along the right side of a certain set of lines and arcs, but that task is impossible like in your example, it gives an error and stops. It does not try to guess what IS possible and maybe close enough to what you want... That way lies madness (and ruined work). It is better to give a clear error saying why the requested task is impossible, and then the gcode programmer can fix the problem. But I would like not to include compensation in the code so that I can manually tweak it, if I need it and that is why I like the G41/G42 commands as they do all the job. One thing you might consider is having the CAM compensate the path for your nominal tool diameter but leave in the G41/G42. Then run with a tool diameter of zero in your tool table, or if you want tweak the path, run with a very small positive or negative tool diameter that's the difference between your CAM's idea of the nominal tool and the actual tool. This makes G41/G42 move the path only a tiny amount as if there was a tiny tool. Offsetting a tiny amount makes it much less likely that you will have unreachable moves. Is there a way to tell EMC that such a concaved corners are acceptable and EMC should move on? I think that plasma and laser tables also might be affected by this situation. Nope, for the reasons above. Chris -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
On Thu, Aug 19, 2010 at 09:45:39AM -0500, Stuart Stevenson wrote: Chris, Sorry for the catty remark it's just that we have had several conversations about cutter compensation routines. :) Yes but thanks for that reminder. I want to be clear enough about what is going on here for everyone who is interested to follow. Also your question led me to an idea that might help Viesturs (in my second response to him). Chris -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
2010/8/19 Chris Radek ch...@timeguy.com: Yes I agree the ideal solution is to know what the *desired* behavior is and then do it - however there are two problems with that - knowing what the desired behavior is - and then doing it. I don't mean to be flippant, but both are very hard. Like Stuart S implied with his question, you don't actually program a part profile in gcode. EMC doesn't know anything about the shape of your desired part. It simply has a series of lines and arcs. It moves the tool along this path, or along the right or left of it. If you tell it to move the tool along the right side of a certain set of lines and arcs, but that task is impossible like in your example, it gives an error and stops. It does not try to guess what IS possible and maybe close enough to what you want... That way lies madness (and ruined work). It is better to give a clear error saying why the requested task is impossible, and then the gcode programmer can fix the problem. Well, yes, fair enough! I completely understand this reasoning! EMC should not guess, what is right or wrong, but only execute the given code. Ok, but then how comes I do not receive this error, when cutting a rectangular hole in material, which is defined by 4 G01 moves (and G41 or G42 is active) - there is sharp 90 degree corner and round tool - so the corner cannot be completely reached. But somehow EMC solves the task. That is why I suspect that EMC already has some logic applied for cutting inner corners - it simply offsets the path of the tool be the amount which is equal to the half of the tool's diameter (equal to it's radius) - please correct me, if I am wrong here. And that is what should be done also in this situation - taking the example from the screenshot You provided - if the tool path was offset to the right side, the corner would be exactly where the tool is displayed. As we already agreed, that is the desired behavior. I am sorry, but I do not really understand, why it is ok for corner, where it is turn by 90 degrees, but error is produced, if the corner is sharper than 90 degrees. Are there some limitations on how the path of the tool is offset, when G41/G42 is activated? But I would like not to include compensation in the code so that I can manually tweak it, if I need it and that is why I like the G41/G42 commands as they do all the job. One thing you might consider is having the CAM compensate the path for your nominal tool diameter but leave in the G41/G42. Then run with a tool diameter of zero in your tool table, or if you want tweak the path, run with a very small positive or negative tool diameter that's the difference between your CAM's idea of the nominal tool and the actual tool. This makes G41/G42 move the path only a tiny amount as if there was a tiny tool. Offsetting a tiny amount makes it much less likely that you will have unreachable moves. Sorry, but I do not see the difference, I still have to include the compensation in the code by CAM programm. I like the ability that I can quickly adjust the code by hand rather than doing it in CAM application or releasing clamps and repositioning the material on the table and then clamping it down again. I can still edit it manually, but having the compensation already included in the code creates more room for my mistake, so that is why I had this question. Ok, seems like I will have to live with that. Chris, did manage to check the second code sample I provided? Is EMC showing error there? Viesturs -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
Viesturs Lācis wrote: (...) I am sorry, but I do not really understand, why it is ok for corner, where it is turn by 90 degrees, but error is produced, if the corner is sharper than 90 degrees. Are there some limitations on how the path of the tool is offset, when G41/G42 is activated? Did you use G64 Ptolerance when using G41/42 to cut a corner ? This could explain why it did not produced an error. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
On Thu, Aug 19, 2010 at 10:48:37AM -0500, Viesturs L??cis wrote: Ok, but then how comes I do not receive this error, when cutting a rectangular hole in material, which is defined by 4 G01 moves (and G41 or G42 is active) - there is sharp 90 degree corner and round tool - so the corner cannot be completely reached. But somehow EMC solves the task. You are right - EMC does have handling for concave corners. When two moves come together to form a concave corner, EMC calculates where the tool is tangent to both original moves and puts the offset corner there. The error happens when the tool can't be tangent to both moves forming the corner because it doesn't fit. I am sorry, but I do not really understand, why it is ok for corner, where it is turn by 90 degrees, but error is produced, if the corner is sharper than 90 degrees. Are there some limitations on how the path of the tool is offset, when G41/G42 is activated? Inside a 90 degree corner is a good simple example: if both moves making the 90 degree corner are longer than the tool radius, the tool fits in there. The disconnect here is you are thinking of a corner as where I think a corner should be on my part, even if there are several little moves in the gcode that the tool can't get in there to touch without gouging the part but EMC thinks of a corner as the point where *two* adjacent moves come together. EMC handles a corner concavity of *two* adjacent moves. EMC does not handle throwing away a whole series of unwanted moves to make a new corner out of non-adjacent moves. This makes G41/G42 move the path only a tiny amount as if there was a tiny tool. ?Offsetting a tiny amount makes it much less likely that you will have unreachable moves. Sorry, but I do not see the difference, I still have to include the compensation in the code by CAM programm. I like the ability that I can quickly adjust the code by hand rather than doing it in CAM application or releasing clamps and repositioning the material on the table and then clamping it down again. I can still edit it manually, but having the compensation already included in the code creates more room for my mistake, so that is why I had this question. Ok, seems like I will have to live with that. I think you did not understand what I meant - I wish I could be more clear. If the CAM does compensation for the nominal tool size, you can move the path a little bit by using a small positive or negative diameter in your tool table. This will work better. Chris, did manage to check the second code sample I provided? Is EMC showing error there? No, I haven't done that. I'd rather explain the error to you so you can debug the particulars once you understand it. Chris -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
On Thu, Aug 19, 2010 at 06:06:58PM +0200, yann jautard wrote: Did you use G64 Ptolerance when using G41/42 to cut a corner ? This could explain why it did not produced an error. This is unrelated. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
2010/8/19 Chris Radek ch...@timeguy.com: The disconnect here is you are thinking of a corner as where I think a corner should be on my part, even if there are several little moves in the gcode that the tool can't get in there to touch without gouging the part but EMC thinks of a corner as the point where *two* adjacent moves come together. EMC handles a corner concavity of *two* adjacent moves. EMC does not handle throwing away a whole series of unwanted moves to make a new corner out of non-adjacent moves. Do I understand correctly that in this case error is produced, because in the corner there are G01 moves which are smaller than tool? And EMC cannot execute them, if G41/G42 is active and tool size has to be compensated? If that is so, then I do not see a way to debug it - CAM programm won't accept splines any other way than in small straight lines and the file is more than 16k lines long so I doubt I can fix it manually... Ok, I will try to figure out something - client wants to receive the result tomorrow. Chris, did manage to check the second code sample I provided? Is EMC showing error there? No, I haven't done that. I'd rather explain the error to you so you can debug the particulars once you understand it. I think that it is somehow different, because tool has to move along the outer side of the G02 move, so I do not understand, where is the concave corner created there. Could You please take a look? Viesturs -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
For me this is an issue I have to deal with quite often, - so I'm very humbly going to put my 2 cents in. I realize that probably everyone has their own idea of what the ideal solution is, and wholeheartedly respect that what may seem to be a minor change from a user perspective can often be massive work from a developer perspective but ideas never hurt so here are mine. On 08/19/2010 10:59 AM, Chris Radek wrote: On Thu, Aug 19, 2010 at 09:31:42AM -0500, Viesturs L??cis wrote: Ok, thank You for the explanation, I kind of realised that it is the case that there is corner that cannot be completely reached, because tool is too big. The way I see the ideal solution - display the error message so that I am warned about the situation, and continue with the code. Using Your screenshot - the displayed tool position would be the point, where tool should do the corner - stop and start moving downwards. That is the desired behavior in current situation. Yes I agree the ideal solution is to know what the *desired* behavior is and then do it - however there are two problems with that - knowing what the desired behavior is - and then doing it. I don't mean to be flippant, but both are very hard. Like Stuart S implied with his question, you don't actually program a part profile in gcode. EMC doesn't know anything about the shape of your desired part. It simply has a series of lines and arcs. It moves the tool along this path, or along the right or left of it. It seems to me that just having a configuration option somewhere, or a register, or a parameter, or a menu choice somewhere - such as whether to treat the condition as an error, warning, or silent, and knowing the result - would help to solve the desired unknown. For myself, in most situations it would be very convenient to just follow the path and leave what it cannot reach, - for other machinery or users or applications it might be unacceptable and an error condition could be a life-saver. I believe flexibility, where possible is always desirable. As for implementing the behavior, I guess that could be very easy and well worth it, or very hard and not. But I would imagine that there must already be some behavior that leaves material in shallow angles up to a certain point without generating an error? - since a circle can never cross a vertex from inside an angle without crossing a line. Or maybe it handles it another way - I have no idea. One thing you might consider is having the CAM compensate the path for your nominal tool diameter but leave in the G41/G42. Then run with a tool diameter of zero in your tool table, or if you want tweak the path, run with a very small positive or negative tool diameter that's the difference between your CAM's idea of the nominal tool and the actual tool. I think possibly for many EMC users, CAM is not an easy thing. Many plasma applications are using artistically oriented patterns and programs, such as clipart or truetype font cutouts and without a decent CAM, offset functionality can be a huge advantage. One could argue that offset functionality is a CAM issue altogether, but fortunately, there is a G-code for it :) -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
here we go again :) On Thu, Aug 19, 2010 at 11:29 AM, Thomas D. madsc...@gmail.com wrote: For me this is an issue I have to deal with quite often, - so I'm very humbly going to put my 2 cents in. I will contribute 2 cents also I realize that probably everyone has their own idea of what the ideal solution is, and wholeheartedly respect that what may seem to be a minor change from a user perspective can often be massive work from a developer perspective but ideas never hurt so here are mine. cannot disagree with this statement It seems to me that just having a configuration option somewhere, or a register, or a parameter, or a menu choice somewhere - such as whether to treat the condition as an error, warning, or silent, and knowing the result - would help to solve the desired unknown. For myself, in most situations it would be very convenient to just follow the path and leave what it cannot reach, - for other machinery or users or applications it might be unacceptable and an error condition could be a life-saver. I believe flexibility, where possible is always desirable. wholeheartedly agree here!!! thanks Stuart -- dos centavos -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
On Thu, Aug 19, 2010 at 12:29:39PM -0400, Thomas D. wrote: I realize that probably everyone has their own idea of what the ideal solution is, and wholeheartedly respect that what may seem to be a minor change from a user perspective can often be massive work from a developer perspective but ideas never hurt so here are mine. So very true. It seems to me that just having a configuration option somewhere, or a register, or a parameter, or a menu choice somewhere - such as whether to treat the condition as an error, warning, or silent, and knowing the result - would help to solve the desired unknown. For myself, in most situations it would be very convenient to just follow the path and leave what it cannot reach, - for other machinery or users or applications it might be unacceptable and an error condition could be a life-saver. I believe flexibility, where possible is always desirable. As for implementing the behavior, I guess that could be very easy and well worth it, or very hard and not. But I would imagine that there must already be some behavior that leaves material in shallow angles up to a certain point without generating an error? - since a circle can never cross a vertex from inside an angle without crossing a line. Or maybe it handles it another way - I have no idea. Let me try to explain an example. I really think the disconnect between how I as a programmer think about it and how a user thinks about it is our different understanding of what a corner is. I tried to explain this in my last message. Say you are cutting inside a bunch of square pockets. If you use a reasonable tool size for it the offset path is some smaller squares. If you use a larger tool diameter, the offset path gets smaller. At some point, as you keep enlarging the tool, when the diameter of the tool is larger than the side of the square, the offset path disappears (it becomes a square with NEGATIVE side length). At this point EMC will give you an error because it can't make the tool follow inside that path anymore. Note EMC doesn't know these pockets are squares. But when it calculates these endpoints generated by finding where the tool fits inside the corner, and sees that they are connected by degenerate lines, it errors. (EMC considers two corners at a time because you need to know two endpoints to make a compensated move. These corners are defined by the three nearby moves. This is the extent of its knowledge of your programmed motions as it moves along.) I understand you want it to keep going in some cases of degenerate paths, and I do too. But without knowing things it can't know (like conceptually what the part looks like) it can't keep going without guessing. In your program that cuts a hundred square pockets, what does it mean to keep going if the tool doesn't fit in them? Chris -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
2010/8/19 Chris Radek ch...@timeguy.com: Let me try to explain an example. I really think the disconnect between how I as a programmer think about it and how a user thinks about it is our different understanding of what a corner is. I tried to explain this in my last message. Say you are cutting inside a bunch of square pockets. If you use a reasonable tool size for it the offset path is some smaller squares. If you use a larger tool diameter, the offset path gets smaller. At some point, as you keep enlarging the tool, when the diameter of the tool is larger than the side of the square, the offset path disappears (it becomes a square with NEGATIVE side length). At this point EMC will give you an error because it can't make the tool follow inside that path anymore. Note EMC doesn't know these pockets are squares. But when it calculates these endpoints generated by finding where the tool fits inside the corner, and sees that they are connected by degenerate lines, it errors. (EMC considers two corners at a time because you need to know two endpoints to make a compensated move. These corners are defined by the three nearby moves. This is the extent of its knowledge of your programmed motions as it moves along.) I understand you want it to keep going in some cases of degenerate paths, and I do too. But without knowing things it can't know (like conceptually what the part looks like) it can't keep going without guessing. In your program that cuts a hundred square pockets, what does it mean to keep going if the tool doesn't fit in them? I think that I understand the explanation of programmer's point of view very well. So I have a question - how difficult is it to achieve following behavior: skip those lines of code in concave corner, which are smaller than tool, and continue, if there is any other G0 or G1/G2/G3 code to be executed. In Your example all the square pockets would be skipped and outside contour would be cut. In my example I would get, what I want. My idea, how to achieve this, is : 2010/8/19 Chris Radek ch...@timeguy.com: You are right - EMC does have handling for concave corners. When two moves come together to form a concave corner, EMC calculates where the tool is tangent to both original moves and puts the offset corner there. If 1) tool is in situation, where it is a tangent to 2 lines - one, that has just been executed and the other - one that has not yet be done and 2) that second tangent line is not the next line in the queue then skip all the remaining G1/G2/G3 lines so that the line, which is tangent of the tool and which is not yet executed, is next in the queue and execution of the code is resumed from there. How hard is that from programmer's point of view? This would solve my problem that code consists of very small straight moves. I know that using some other CAM programm would solve the cause of the issue rather than trying to workaround the consequences like I am trying now... I understand that there might be other commands beside G1/G2/G3 and other special cases... Viesturs -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
Do you have the CAD program too? To help your CAM package with tangent arcs to eliminate the unreachable corners. The easier way would be to tell your CAM package to compensate for tool diameter, it would create a tool path at the center of the tool, always keeping the tool tangent to the feature shape you defined, staying out of the corners you can't reach. The CNC machine then is told the tool radius is zero. Cutter comp is made/showing incrementally. Point I am trying to make is, often code causes trouble with cutter comp if you use what we call radial comp, what is described above we call center comp. Radial comp can be easier when programming manually, as you can use print dimensions directly. Center comp code is easier portable between machines for one, as you don't get tripped up by different methods/types of error handling. If you have a CAM package that can compensate for the tool diameter and output a tool path along the center of the tool, I can only urge you to start using it. If your CAM package allows you to create arcs from 3 points you could probably create arcs out of the many straights, picking the beginning and end should be easy and pick the middle to create the arc. If your CAM software really does not support this, maybe you can represent the splines with blending arcs. You could create 2 perpendicular lines through the center of the first and the last segments, they should meet in the center of the arc they represent. You should be able to create an arc from two points and the center. Enough of those let's you represent a spline with few arcs instead of many lines. Not sure what you cut, what tolerances you look at, since this is a little fudgy, this may or may not work for you. I'd try to get the most out of my CAM before going this route. On Aug 19, 2010 7:59 AM, Viesturs Lācis viesturs.la...@gmail.com wrote: Hello, guys! I have been running my waterjet cutting machine with EMC for a while now (currently that is version 2.4.3.1) and I have gathered few questions about the way, how EMC interprets the g-code. The main issue is that sometimes I receive this error message: Arc move in concave corner cannot be reached by the tool without gouging It also indicates the number of the line in the g-code, which is near the one, causing error. So I found that in the following piece of code the G3 move was the problem: G1 X+115.175 Y+245.013 G3 X+118.786 Y+245.339 I+1.484 J+3.720 G1 X+120.236 Y+246.394 I have G41/G42 tool diameter compensation commands included as well as there is M6 T1 command in the beginning of the file and in the tool table I have saved the size of the water jet as a tool number one, so that EMC compensates the kerf size. The confusion is caused by the fact that saved diameter is 1.1 mm and in the code above we can see that radius of the G3 move is larger than half of the tool's diameter, which has to be offsetted. I just received also this error message: Straight feed in concave corner cannot be reached by the tool without gouging It indicated that the error is around line 24, so here is the part of the code: G1 X+167.031 Y+46.741 G1 X+167.643 Y+46.983 G1 X+168.223 Y+47.330 G1 X+168.364 Y+47.433 G1 X+168.364 Y+23.726--line24 G1 X+147.289 Y+23.726 G1 X+147.289 Y+54.982 The code consists of very small G1 moves. Unfortunately the CAD drawing consisted almost only of splines, which are not very welcome by my CAM application, so it converted the splines in very small straight segments. That is why that file consists of 16344 lines, so I do not see an option of manual correction of the code. Can anyone explain, what is that EMC does not like about the g-code and what can I do to correct it? Thank You in advance! Viesturs -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
On Thu, Aug 19, 2010 at 12:41:02PM -0500, Viesturs L??cis wrote: In Your example all the square pockets would be skipped and outside contour would be cut. In my example I would get, what I want. It cannot possibly be safe to throw away part of the program and then continue on with the rest of the program. Think about all the ways that can cause disaster. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
... snip Are there any issues with adding an inside radius feature to the part? Making it as large as acceptable may allow the operator to use a range of tool radii without changing the program or the resulting part. It seems better to fix problems on the front end (designing with fabrication in mind), if you can, rather than the end (impossible to make part, fixed by the machinist without documentation). I think the g-code should be as lean as possible and leave the fluff to CAM and pre/post-processors. (I'm not trying to be critical, just exploring the issue.) -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
On Fri, 2010-08-20 at 07:00 +1000, Frank Tkalcevic wrote: Yes, the problem is just what the error message says. There is a move that makes a concave corner but the move cannot be reached (the tool cannot move alongside it as you request) without gouging into the profile of the part. Here is a screenshot showing the situation. http://timeguy.com/cradek-files/emc/viesturs-error.png Is oversimplifying the problem? Looking at the screen shot shows the line segment in question highlighted in blue. This isn't a simple question of a tight corner. It is the whole line segment is unreachable without, as the error says, gouging the part. From the screen grab, the line segment before looks unreachable too. (assuming left to right movement) To do this properly, EMC would need to preprocess a lot more than the next line segment to get this correct. It seems to be asking a bit much of EMC. H! Unfortunately, the CAM program can't read your mind so it is forced to do what ever the drawing spec's. Synergy (www.webersys.com) takes an interesting approach; it will cut into the corner as far as it can w/o gouging. Then you either use a smaller cutter or the corner routine with a smaller cutter to appropriately clean out the corners. CAM has to take a conservative approach just to stay out of trouble. One can hand program simple stuff and stay out of trouble. B-splines, etc ... one pretty much has to trust the CAM to do the job correctly. It is too bad but occasionally one must think and plot pretty seriously to fool emc, or any other system, into doing what you want. Life is like that. Dave -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Code interpretation in EMC
Hi! As far as I understand from the other replies, EMC should not be the software that solves these problems. However, as I develop on a gcode manipulating software, maybe this would be better suited. http://code.google.com/p/grecode/ All the gcodes are read to memory, and it would be relatively little work to find these concave corners, and do automatic joining of line segments, especially near the corners. However, I am a bit short on time currently to implement this. If you know/want to learn C++, and like hacking a bit, maybe my code could be a nice starting point. Btw, I had similar problems with radius compensation, while hacking the gears-gcode-creator at http://www.thingiverse.com/thing:1963 very nice greetings, bernhard On 8/19/2010 2:54 PM, Viesturs Lācis wrote: Hello, guys! I have been running my waterjet cutting machine with EMC for a while now (currently that is version 2.4.3.1) and I have gathered few questions about the way, how EMC interprets the g-code. The main issue is that sometimes I receive this error message: Arc move in concave corner cannot be reached by the tool without gouging It also indicates the number of the line in the g-code, which is near the one, causing error. So I found that in the following piece of code the G3 move was the problem: G1 X+115.175 Y+245.013 G3 X+118.786 Y+245.339 I+1.484 J+3.720 G1 X+120.236 Y+246.394 I have G41/G42 tool diameter compensation commands included as well as there is M6 T1 command in the beginning of the file and in the tool table I have saved the size of the water jet as a tool number one, so that EMC compensates the kerf size. The confusion is caused by the fact that saved diameter is 1.1 mm and in the code above we can see that radius of the G3 move is larger than half of the tool's diameter, which has to be offsetted. I just received also this error message: Straight feed in concave corner cannot be reached by the tool without gouging It indicated that the error is around line 24, so here is the part of the code: G1 X+167.031 Y+46.741 G1 X+167.643 Y+46.983 G1 X+168.223 Y+47.330 G1 X+168.364 Y+47.433 G1 X+168.364 Y+23.726--line24 G1 X+147.289 Y+23.726 G1 X+147.289 Y+54.982 The code consists of very small G1 moves. Unfortunately the CAD drawing consisted almost only of splines, which are not very welcome by my CAM application, so it converted the splines in very small straight segments. That is why that file consists of 16344 lines, so I do not see an option of manual correction of the code. Can anyone explain, what is that EMC does not like about the g-code and what can I do to correct it? Thank You in advance! Viesturs -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
