Webcontrol lost USB connection/lost calibration

[ShadyG]

I have seen several posts regarding USB connection lost, lost calibration etc.

I had a sled not keeping up followed by lost usb connection and the warning that the machine had lost it’s calibration. I was quickly able to determine that the machine was still in calibration however I could not restart the cut from the GC line it stopped on, the motors would hum and the lost usb connection would come up again. I stripped out the already cut Gcode and restarted the file, the motors would just hum. I went to line 2 of the new file and it started to cut but the units changed to inches, I stopped it before damage was done. Changed the units back to mm and restarted the file on line 1, cut proceeded normally. This happened three times (three separate events) the same way. Now ultimately the sled not keeping up was caused by my ghetto sled weight setup hanging on an already cut pocket. But this problem happend twice while cutting and I ran into it again when I shutdown cutting last night because I was too tired. If there is a large amount of GCode between the start and your goto line this is the result I am getting in the most recent version of webcontrol. You also have to start from home when restarting. I even tried starting the original full file and then using the goto feature and had the same result. So you have to shorten up the file and then you may need to play with it (switch to another line and then back to line 1) in order to get the cut down file to run.

So part of this is a bug report for Webcontrol the other part of this is to hopefully help others, I have seen several related posts regarding webcontrol.

If your maslow stops, once you make it safe, take a picture of the webcontol screen, you will need the line number it stopped on and you may need the home position, I did have that get lost once in all of this as well.

I have a work around now but I hope this helps someone else.

[Orob]

This is a disturbing find. Thank you for sharing the details. I have a few clarification questions:

1. How many line are in you gcode file and how far in does it crash?

2. Do you have the buffer gcode option enabled or disabled in your webcontrol settings? If on, turn off.

3. When you had to switch units to mm (again) was that after a recalibration and starting the gcode mid-file?

Thanks again for you efforts.

[ShadyG]

Hi Orob,

You know it was late last night and I forgot to mention this was all using Fusion 360 cam which has been substancially nuetered. I don’t think this is part of the issue but worth considering.

1. Roughly 125,400, it originally crashed on or about 44,100, again this was first preceded (the first time) by a sled hang and sled not keeping up error.
2. I do not use the buffer Gcode option.
3. No recalibration was necessary, the unit never lost calibration even though it threw that error. For lack of a better term the system was just confused, manual sled movement was normal and accurate, none of the values in settings had changed and home was accurate, but until I rebooted a couple of times and tried different scenarios it would not cut anything but the full original file. Then I started working with the already cut Gcode removed, the first time I started the truncated file(s) it would refuse to cut, then I would goto to line 2 and it would operate but the units would change to inches. Next full stop, change units and restart at line one and the unit would proceed as one would expect.

It is my belief that something “unexpected” happens and the program doesn’t know what to do with it, so it throws the usb connection lost/calibration lost error, but in my case there was noSea Bee 1.nc (3.5 MB) loss of calibration, although it is possible that re-calibration might have resolved the issue it was not necessary. I have attached the gcode file, it is a sign for a friend who was a Sea Bee in the military and is preparing for a reunion.

Thanks, we are all in this together!

[dlang]

the loosing calibration error means that the machine no longer knows where it
is. As part of it’s operation, it has to both calculate what lengths of chain it
needs to have out to be at the right place, and calcullate where it currently is
based on the chain length that is fed out.

If there is a problem with the second calculation, it throws the ‘lost
calibration’ error

when the machine loses the USB connection, it also loses track of where it is
(also if it’s powered down unexpectedly)

the fix for all these problems is to set the chains to a known position (this is
the ‘set sprockets to 12 oclock, set marked links of chain on the sprockets’
routine)

the second problem you have of picking up where you left off in the gcode is
another difficult issue. The problem is that there are gcodes that change the
behavior of future gcode commands, so if you start from scratch and skip those
codes, the result is not what you expect.

typically there is a header section with various codes before you get to
g0/g1/g2/g3 codes that do most of your cutting. if you keep those and only strip
out g0-g3 codes you have a fair chance of picking up where you left off.

Another thing that frequently works is to fast forward to the next Z movement.

again, these don’t always work, but they frequently work.

David Lang

Date: Mon, 21 Dec 2020 08:52:06 +0000
From: ShadyG via Maslow CNC Forums maslowcnc@discoursemail.com
Reply-To: Maslow CNC Forums
maslowcnc+0a1bfc994accf224fa1e0913caf5dae6@discoursemail.com
To: david@lang.hm
Subject: [Maslow CNC] Webcontrol lost USB connection/lost calibration

I have seen several posts regarding USB connection lost, lost calibration etc.

I had a sled not keeping up followed by lost usb connection and the warning that the machine had lost it’s calibration. I was quickly able to determine that the machine was still in calibration however I could not restart the cut from the GC line it stopped on, the motors would hum and the lost usb connection would come up again. I stripped out the already cut Gcode and restarted the file, the motors would just hum. I went to line 2 of the new file and it started to cut but the units changed to inches, I stopped it before damage was done. Changed the units back to mm and restarted the file on line 1, cut proceeded normally. This happened three times (three separate events) the same way. Now ultimately the sled not keeping up was caused by my ghetto sled weight setup hanging on an already cut pocket. But this problem happend twice while cutting and I ran into it again when I shutdown cutting last night because I was too tired. If there is a large amount of GCode between the s
tart and your goto line this is the result I am getting in the most recent version of webcontrol. You also have to start from home when restarting. I even tried starting the original full file and then using the goto feature and had the same result. So you have to shorten up the file and then you may need to play with it (switch to another line and then back to line 1) in order to get the cut down file to run.

[ShadyG]

David,

I can tell you for certain the machine never lost it’s location even though it threw that error. I was able to continue the cut three times without re-calibration and without anomalies in the cut.

I left the headers in the edited files. It is either something in webcontrol or the Gcode the hobby version of Fusion now generates causing an issue. Again the first try on a cut down file the motors just hum. Stop, go to line two and the machine starts moving but the units change in inches. Stop, reset the unit and goto line 1 and the file cuts as if nothing was ever amiss.

I make no claim to be an expert, but I do know how to troubleshoot a system, replicate findings and isolate issues. If this is a webcontrol or fusion issue either way it is worth talking about and investigating.

[Orob]

Is line 1 G21? G21 is metric, G20 is imperial units.

[ShadyG]

This is the header and the first few lines of the first file where I removed the previously cut Gcode.

(SEA BEE 1A)
G0 G40 G90 G17
G21
(WHEN USING FUSION 360 FOR PERSONAL USE, THE FEEDRATE OF )
(RAPID MOVES IS REDUCED TO MATCH THE FEEDRATE OF CUTTING )
(MOVES, WHICH CAN INCREASE MACHINING TIME. UNRESTRICTED )
(RAPID MOVES ARE AVAILABLE WITH A FUSION 360 SUBSCRIPTION. )

(POCKET3)
T1
M3 S10000
G1 X243.031 Y373.724
G1 Z3.785
G1 X242.953 Y373.749 Z3.474 F333.
G1 X242.848 Y373.787 Z3.358
G1 X242.745 Y373.828 Z3.242
G1 X242.604 Y373.892 Z3.196
G1 X242.468 Y373.963 Z3.15
G1 X242.279 Y374.075 Z3.142
G1 X242.099 Y374.202 Z3.135

[md8n]

@ShadyG

(WHEN USING FUSION 360 FOR PERSONAL USE, THE FEEDRATE OF )
(RAPID MOVES IS REDUCED TO MATCH THE FEEDRATE OF CUTTING )
(MOVES, WHICH CAN INCREASE MACHINING TIME. UNRESTRICTED )
(RAPID MOVES ARE AVAILABLE WITH A FUSION 360 SUBSCRIPTION. )

OK, So does that mean I have to add yet another option to my GCodeClean so that it cranks G0 up to full speed in all cases?

[ShadyG]

That would be great!

[dlang]

one problem I see is that there is no feed rate before the 3rd G1 line. IIRC the
default feed rate is so small that the motors make noise, but you don’t see
visible movement.

David Lang

[md8n]

@ShadyG

F333.

In this case it’s effectively assuming whatever feed rate was set in there before hand - which probably isn’t what you want (it was probably a Z-Axis move, with a feedrate of something like F12)

[ShadyG]

Here is the header and the first few lines of the full file. It starts and runs everytime.

(SEA BEE 1)
G0 G40 G90 G17
G21
(WHEN USING FUSION 360 FOR PERSONAL USE, THE FEEDRATE OF )
(RAPID MOVES IS REDUCED TO MATCH THE FEEDRATE OF CUTTING )
(MOVES, WHICH CAN INCREASE MACHINING TIME. UNRESTRICTED )
(RAPID MOVES ARE AVAILABLE WITH A FUSION 360 SUBSCRIPTION. )

(POCKET3)
T1
M3 S10000
G0 X35.747 Y46.824
G0 Z6
G1 Z4 F762.
G1 Z3.785 F333.
G1 X35.696 Y46.888 Z3.474

[mooselake]

@ShadyG

G1 Z4 F762

You removed this line which set the initial feedrate.

[ShadyG]

Ok, that does not explain why it switches from mm to inches and I did not see a decrease in speed. So while I don’t necessarily disagree with what you are presenting the behavior of the machine suggests there is more to it.

[Orob]

That switch to inches is a tough one. The maslow firmware runs in mm, so internally it converts everything by changing the conversion factor from 1 (MILLIMETETERS) to 25.4 (INCHES) - this may seem counter intuitive, but it divides by that number in all cases. This is where it is set in the lines below in the gcode parser in the Mega firmware:

Webcontrol keeps track of what the setting is so it will display correctly on the workspace canvas…

Looking through your header, I don’t think I found your problem, but I found another one…

G0 → rapid positioning

webcontrol: draws a line in the viewer
Mega firmware: interestingly, the Mega firmware treats G1 and G0 the same, so the gcode cleaner change from G1 to G0 really doesn’t do anything except that there is a feed rate that is included with G1 that probably slows things down.

G40 → turns off cutter compensation

webcontrol: ignores
Mega firmware: already off, ignores

G90 → according to gcodetutor.com: G90 is for absolute units (incremental units is G91)

webcontrol: sets absolute flag to false (G91 sets it to true) !!! this is backwards!!!

Mega firmware: sets relative units (another way to describe incremental) flag to false (G91 sets it to true)

G17 → set xy plane as coordinate plane

webcontrol: ignore XY is the default
Mega firmware: valid code, does nothing

G21 → system units to mm (G20 is inches)

webcontrol: units to mm (G20 is inches). the setting of the system units in webcontrol is only done in one file gcode.py here:

and only checked in the action.py file here:

Mega firmware: sets units to mm (G20 is inches). Only sets it in one spot and calls that value for all x, y, and z operations.

T1 → use tool #1

webcontrol: sets the drawing tool flag
Mega firmware: sets a flag to remind the user when a G06 is issued

Beyond that, why are all the z values positive? By convention the surface is 0 and when cutting, the z value should be negative.

[ShadyG]

That is one heck of an analysis. I am a litte confused about the positive Z question as there are negative values in the complete files beyond the few header and few lines I posted most recently.

I think autodesk made a huge mistake neutering the CAM functionality in Fusion 360. It makes me want to go back to finding a solution completely outside of Fusion 360 and never giving them my business. I understand the non-commercial license but this is just ridiculous.

At least in my case the sled not keeping up->usb connection lost->calibration lost, turned out to be a false flag, well at least the calibration lost was. Whatever contributed to the error sure had the machine bound up though. I really wish there was an adjustment in Estlcam tolerance which should cut down on the extraneous movements that slow down the Maslow.

Thanks to all for taking the time to discuss these things.

[mooselake]

Do you m

@md8n

OK, So does that mean I have to add yet another option to my GCodeClean so that it cranks G0 up to full speed in all cases?

Maybe convert G1 moves at or to the safe height to G0s? I don’t use F360 but there might be some other relatively easy fixes to add back what they took away?

Kirk

[md8n]

@mooselake

Maybe convert G1 moves at or to the safe height to G0s?

It already does this

[Arnd]

Would it be possible to add a function to save “home positions” plz?!

Then, i am constantly struggling with con losses even after i moved my raspberry close to the adruino using a very short USB cable. So it doesnt has anything todo with cable lenght and induction currents etc.

As far as i see it the Arduino rebooted when webcontrol reports USB con loss. Any tips on how to debug why its rebooting? How to distinguish between a possible soft reboot and a hardware malfunction?

Is there any software which will test your arduino and possibly motor controller?

[ShadyG]

No snark intented, I figured out seperately to make sure the power cord was fully inserted into the Arduino. The only other thing I can suggest is trying a UPS for filtered power. Brown-outs and noisy power can cause weird stuff.