[Grbl_Esp32 Issue#734] Skipping To A New Position During Cutting But Didn’t Loose Home Position

#3 – jaysettle 于 2021-04-12

This happened again on me last week. I had already replaced my usb cord with this one:
https://www.amazon.com/gp/product/B00C7SA21U/ref=ppxyodtbsearchasintitle?ie=UTF8&psc=1

The combination of gold-plated connectors, bare copper conductors, and foil & braid shielding provides superior cable performance and error-free data transmission via USB cable extension.

It is a 3.0 10ft extension usb A to B but is 2.0 capable. I don’t see anyone else having this problem otherwise they would have commented here so I have to assume it’s something with my setup.

#4 – jaysettle 于 2021-04-18

Could this issue I’m seeing be related to this?
https://discord.com/channels/780079161460916227/785937382548832256/827525017452544000

#5 – jaysettle 于 2021-04-25

This happened again last night. Cutting a sign for a client and the machine suddenly skipped to a new position.

I stopped the job and hit “Return To Zero” and it returned to the same point the job started at.

!IMG_1466
!IMG_1464
!IMG_1465

#6 – atsukita1969 于 2021-08-10

I had same problem with my laser, too.
My case, I got improvement with following change.

1. Add default stepping motor current setting “Machines/driver.h”
#define DEFAULTXCURRENT **
#define DEFAULTXHOLD_CURRENT **
(my case, machine has ganged Y axis, Y and Y2 also added.)

2 Motor current saving
during G code program, steeper motor had hot with max current.
I use 75% of default current and 40% of hold current instead of motor max current.

!image

#7 – jaysettle 于 2021-08-10

Hey this was due to a “uart” coms bug. They fixed it in a firmware with a new uart driver.

I’m sorry I don’t know which version but I believe it was like 7 months ago or something. I had to flash my controller with the updated firmware and it hasn’t skipped yet.

-Jay

> On Aug 10, 2021, at 1:25 AM, atsukita1969 @.*> wrote:
>
> 
> I had same problem with my laser, too.
> My case, I got improvement with following change.
>
> Add default stepping motor current setting “Machines/driver.h”
> #define DEFAULTXCURRENT **
> #define DEFAULTXHOLD_CURRENT **
> (my case, machine has ganged Y axis, Y and Y2 also added.)
> 2 Motor current saving
> during G code program, steeper motor had hot with max current.
> I use 75% of default current and 40% of hold current instead of motor max current.
>
>
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or unsubscribe.
> Triage notifications on the go with GitHub Mobile for iOS or Android.

#8 – atsukita1969 于 2021-08-11

You solved problem. Good news.

I had this movement error even latest firmware.

Thanks for your info.

#9 – jaysettle 于 2021-08-11

Oh no. I hope it never comes back.

-Jay

> On Aug 10, 2021, at 8:01 PM, atsukita1969 @.*> wrote:
>
> 
> You solved problem. Good news.
>
> I had this movement error even latest firmware.
>
> Thanks for your info.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or unsubscribe.
> Triage notifications on the go with GitHub Mobile for iOS or Android.

#10 – jaysettle 于 2021-09-07

Had the problem again last night. Very disappointed.

-Jay

> On Aug 10, 2021, at 8:07 PM, Jay Settle @.*> wrote:
>
> Oh no. I hope it never comes back.
>
>
> -Jay
>
>
>>> On Aug 10, 2021, at 8:01 PM, atsukita1969 @.*> wrote:
>>>
>> 
>> You solved problem. Good news.
>>
>> I had this movement error even latest firmware.
>>
>> Thanks for your info.
>>
>> —
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub, or unsubscribe.
>> Triage notifications on the go with GitHub Mobile for iOS or Android.

#11 – Bakafish 于 2021-09-08

Are you logging the command input and output? Either a command is getting dropped (due to electrical interference, or some other communication issue) or you are losing steps (a motor cord getting hung up on something, or debris temporarily jamming one of the axis.) Basic CNC’s do not have any way to know when they lose sync with the internal coordinate system. The best way to resolve this is to babysit it until it has an error, then stop it and determine if there was a comms issue (which should show up in the logs as an error) or some physical issue (motion problems or a stepper overheating, etc…)

There is support for G-Code checksums, but you will need to use a g-code sender that supports them. This will ensure that any communication errors that would still be parsable g-code are caught. You also may want to try using local storage (SD Card if you have one) as it isn’t going to suffer from the same kinds of interference.

#12 – bdring 于 2021-09-08

@jaysettle How are you compiling the firmware. Are you using the Arduino IDE or PlatformIO? You mention changing the UART driver. I am not sure what you mean by that, but the true solution is mentioned here.

https://github.com/bdring/Grbl_Esp32/wiki/Compiling-with-Arduino-IDE

Use ESP32 library version 1.0.3

#13 – jaysettle 于 2021-09-08

Check this video around the 3:40 minute mark. This is when my machine stopped. Look at the console. No errors.

https://photos.app.goo.gl/mwTUpewoENSwcL1DA

Also I was able “return to zero” and return to my original zero mark. Very odd.

!image

-Jay

> On Sep 7, 2021, at 10:34 PM, Jason Benguerel @.*> wrote:
>
> 
> Are you logging the command input and output? Either a command is getting dropped (due to electrical interference, or some other communication issue) or you are losing steps (a motor cord getting hung up on something, or debris temporarily jamming one of the axis.) Basic CNC’s do not have any way to know when they lose sync with the internal coordinate system. The best way to resolve this is to babysit it until it has an error, then stop it and determine if there was a comms issue (which should show up in the logs as an error) or some physical issue (motion problems or a stepper overheating, etc…)
>
> There is support for G-Code checksums, but you will need to use a g-code sender that supports them. This will ensure that any communication errors that would still be parsable g-code are caught. You also may want to try using local storage (SD Card if you have one) as it isn’t going to suffer from the same kinds of interference.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or unsubscribe.
> Triage notifications on the go with GitHub Mobile for iOS or Android.

#14 – jaysettle 于 2021-09-08

I’m uploading via platform.io. As far as uart, I thought there was a fix for uart in the build I upload via platform.io. I can try another latest upload.

-Jay

> On Sep 7, 2021, at 11:11 PM, bdring @.*> wrote:
>
> 
> @jaysettle How are you compiling the firmware. Are you using the Arduino IDE or PlatformIO? You mention changing the UART driver. I am not sure what you mean by that, but the true solution is mentioned here.
>
> https://github.com/bdring/Grbl_Esp32/wiki/Compiling-with-Arduino-IDE
>
> Use ESP32 library version 1.0.3
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or unsubscribe.
> Triage notifications on the go with GitHub Mobile for iOS or Android.

#15 – bdring 于 2021-09-08

PlatformIO should get the version correct.

#16 – jaysettle 于 2021-09-09

How do I know if I’m using Use ESP32 library version 1.0.3?

#17 – Bakafish 于 2021-09-09

If you compile the latest release version using PlatformIO in Visual Studio Code (with all the latest updates), the properly working library is used. Verifying what version of the library is used in whatever binary you may have is technically possible with the right developer tools and know-how, but telling you how to do that is beyond the scope of the proposed solution. The best way to ensure you have a fixed version is to build a ‘known good’ version as specified above.

#18 – bdring 于 2021-09-09

The boot messages tell you the SDK version. I do know know what number 1.0.3 is. Not at home this week.