abnormal motions during cutting

[Witz0]

Plate with lines instead of arcs
From the description it sounds like g-code commands or motion control errors that are inconsistent.

There are many possible causes so tracing this error could be difficult, but especially important if it is an unknown software error that affects all users and requires an issue to be submitted to another repo.

Without extensive knowledge of these systems, I can only think of a few possible causes from previous reading; mostly from the grbl wiki pages and issues:
https://github.com/gnea/grbl/wiki/Known-Issues

• Most likely is electrical interference, which can be chaotic in nature.

  • The grbl repos have many CNC builders' comments about such issues and it is especially significant on plasma systems due to the arc noise.

  • Reviewing design issues photos shows some wiring details and the plastic boxes used to house the electronics.

  • The plastic is great for prototype work since it isolates potential shorts and is easy to rework. However, it also offers little or no shielding like metal would.

  • From the photos, it is unclear exactly what kind of cables and wires are used, but it does not appear to be shielded (poly fiber strands for riser cable type strain relief are visible).

    • Types of exterior grade plenum rated cables with foil shield and drain/ground wire are ideal for data signals outside a metal box.
      • Other considerations are twisted pair (TP) for differential signals (to THC), stranded (patch) cable for flexibility;
      • unshielded cable with solid core wires can be used for jumpers between PCB's in screw terminals, but need to be in a shielded box;
      • Some Cat6 has plastic spline spacer (flexibility?) and Cat7 has separately shielded pairs.

  • Considering Pros/Cons of designs using a metal box for electronics may be critical.

    • A soild metal box should act as a faraday cage offering good shielding.
    • If used as chassis ground for electronics it must always be isolated from the + (plasma system ground) work circuit, which the table is apart of. User error such as bridging with metal parts is a potential problem.
    • Heat dissipation for a sealed metal box should be considered.
    • A metal box near the table but isolated from it could act as a fairly complete user interface.

• Next, see USB serial transmission errors in arduino clones and some official Arduinos the USB serial chip has bugs; the official ones have a firmware fix.

• Another common noise issue that introduces motion errors is Wiring Limit Switches. Many users add optically isolated limit switches to prevent noise from motors or plasma arcs feeding back as well as better software debouncing.

• A less likely issue now is incorrectly manufactured USB cables. A quick multimeter continuity test between both ends of the exterior plug chasis will tell if they bonded the sheilding to the cable ends correctly.

• Also, useful to know arduino USB spec appears to be v1.1 with max cable lengths of 9.8ft.

A good way to dry run the CNC system to test these errors would be ideal. Disabling the arc would be step one, but video of motions may be insufficient. Maybe a crude plotter (sprung pen/pencil) attachment could be (3D printed?) added to test g-code motions on paper taped to a metal sheet, but I'd guess this would require some software changes as well so expected signals can be ignored.

[jurra]

for the shielding solution, can we also have the shielding metal box inside a plastic box? I have seen these solutions in medical equipment. I found this reference, that expands more on what @Witz0 points: [Grounding and Shielding for your DIY Audio Projects](http://diyaudioprojects.com/Technical/Grounding-Shielding/) I think this "bug" issue, points to other problems that can be separated issues to solve, like designing for safety with regard to electricity, but also other potential hazards. And proper noise reduction, which also involves shielding.

…

On Wed, Aug 29, 2018 at 5:41 AM Abe Anderson ***@***.***> wrote: Plate with lines instead of arcs <https://files.gitter.im/goscommons-github-io/Lobby/aOJA/IMG_0490.JPG> From the description it sounds like g-code commands or motion control errors that are inconsistent. There are many possible causes so tracing this error could be difficult, but especially important if it is an unknown software error that affects all users and requires an issue to be submitted to another repo. Without extensive knowledge of these systems, I can only think of a few possible causes from previous reading; mostly from the grbl wiki pages and issues: https://github.com/gnea/grbl/wiki/Known-Issues - Most likely is electrical interference, which can be chaotic in nature. - The grbl repos <https://github.com/gnea> have many CNC builders' comments about such issues and it is especially significant on plasma systems due to the arc noise. - Reviewing design issues photos <https://github.com/goscommons/CNC-Plasma-Table/tree/master/00_Design_Issues> shows some wiring details and the plastic boxes used to house the electronics. - The plastic is great for prototype work since it isolates potential shorts and is easy to rework. However, it also offers little or no shielding like metal would. - From the photos, it is unclear exactly what kind of cables and wires are used, but it does not appear to be shielded (poly fiber strands for riser cable type strain relief are visible). - Types of exterior grade plenum rated cables with foil shield and drain/ground wire are ideal for data signals outside a metal box. - Other considerations are twisted pair (TP) for differential signals (to THC), stranded (patch) cable for flexibility; - unshielded cable with solid core wires can be used for jumpers between PCB's in screw terminals, but need to be in a shielded box; - Some Cat6 has plastic spline spacer (flexibility?) and Cat7 has separately shielded pairs. - Considering Pros/Cons of designs using a metal box for electronics may be critical. - A soild metal box should act as a faraday cage offering good shielding. - If used as chassis ground for electronics it must always be isolated from the + (plasma system ground) work circuit, which the table is apart of. User error such as bridging with metal parts is a potential problem. - Heat dissipation for a sealed metal box should be considered. - A metal box near the table but isolated from it could act as a fairly complete user interface. - Next, see USB serial transmission errors <https://github.com/gnea/grbl/wiki/Known-Issues#usb-to-serial-transmission-errors> in arduino clones and some official Arduinos the USB serial chip has bugs; the official ones have a firmware fix. - Another common noise issue that introduces motion errors is Wiring Limit Switches <https://github.com/gnea/grbl/wiki/Wiring-Limit-Switches>. Many users add optically isolated limit switches to prevent noise from motors or plasma arcs feeding back as well as better software debouncing. - A less likely issue now is incorrectly manufactured USB cables. A quick multimeter continuity test between both ends of the exterior plug chasis will tell if they bonded the sheilding to the cable ends correctly. - Also, useful to know arduino USB <http://forum.arduino.cc/index.php?topic=27226.msg201939#msg201939> spec appears to be v1.1 with max cable lengths of 9.8ft. A good way to dry run the CNC system to test these errors would be ideal. Disabling the arc would be step one, but video of motions may be insufficient. Maybe a crude plotter (sprung pen/pencil) attachment could be (3D printed?) added to test g-code motions on paper taped to a metal sheet, but I'd guess this would require some software changes as well so expected signals can be ignored. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#43>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARuG0Rp7bWiHrI0LFw_iWaR4ZGXg9Nxpks5uVg1WgaJpZM4WQxTQ> .

[polemidis]

Its not a shielding problem. I am positive. I detected abnormal behavior only when there is a G2 movement (command "G2" on the g-code)
Statistically speaking it would be extremely rare to show up only in G2 moves (these are arcs).

But despite that, shielding is something we have to incorporate into the build, since it will eliminate possible errors to users. Its good to know that right now with unshielded wires, I have not noise in the machine, so one extra step in shielding will make 1000% sure that we will never have to deal with that issue.

The solution to the G2 commands is either
a) tell the g-code generating software (sheetcam )to not use them
b) tell the g-code sender(universal Gcode sender) to transform the g2 arcs into small G1 straight lines before it sends it to the board
c) fine tune the accuracy on the Sheetcam. I have to experiment with the decimal points, and the rounding that is happening at some point.
d) make sure that Sheetcam uses the "Center Format Arc" rather than the "Radius Format"
http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g2-g3

The c) or/and d) looks like the proper way as the b) adds too much load to the processor and the a)also adds huge amounts of code.

[jurra]

@manolis Karamousadakis <polemidis@gmail.com> it would be also nice to explain to Abe the difficulties you had wen using other open source solutions. This is an issue that I don't know if is open in the repo at the moment. But you basically went for sheetcam, to validate the hardware design. The issue of finding an open source solution that works is still open I guess.

…

On Wed, Aug 29, 2018 at 12:44 PM Manolis Karamousas < ***@***.***> wrote: Its not a shielding problem. I am positive. I detected abnormal behavior only when there is a G2 movement (command "G2" on the g-code) Statistically speaking it would be extremely rare to show up only in G2 moves (these are arcs). But despite that, shielding is something we have to incorporate into the build, since it will eliminate possible errors to users. Its good to know that right now with unshielded wires, I have not noise in the machine, so one extra step in shielding will make 1000% sure that we will never have to deal with that issue. The solution to the G2 commands is either a) tell the g-code generating software (sheetcam )to not use them b) tell the g-code sender(universal Gcode sender) to transform the g2 arcs into small G1 straight lines before it sends it to the board c) fine tune the accuracy on the Sheetcam. I have to experiment with the decimal points, and the rounding that is happening at some point. d) make sure that Sheetcam uses the "Center Format Arc" rather than the "Radius Format" http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g2-g3 <http://url> The c) or/and d) looks like the proper way as the b) adds too much load to the processor and the a)also adds huge amounts of code. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARuG0SqkS6cMExR9T3i3vB6sfNaR-2BNks5uVnCHgaJpZM4WQxTQ> .