Erratic motion output and crashing USB serial ports

[stg]

Hooked up a Due running G2 to my CNC a few days back.

Latest (at time of writing 79.6) edge was quite easy to get started with (building, flashing, drivers, all of it) even though building on Windows which I understand is not fully supported yet. I quickly ran into various problems though.

First, the USB serial ports "crash" irrevocably at (seemingly) random times - meaning they stop receiving data, causing a blocking condition in the sending application. Data is instead queued up on the PC, never reaching G2. The only resolution is to power cycle the board. This happens with both Chilipeppr and terminal programs. Some terminal programs (for example Termite) cause this behavior immediately (first command sent after opening port). System is Windows 7 x86 which I know may not be well tested.

The biggest issue though - when sending simple programs to G2, results are very erratic. Movements are randomly skipped past or executed out-of-order. No two executions of the same code give the same results. Status reports are infrequent and sometimes lacking for motions of durations up to several seconds . Each run yields different results for status reports as well. However, positional synchronization is never lost and status reports appear to represent actual position. This is a "vanilla" gShield edge 79.6 with few settings changed (Motor configuration, Velocity-/Feedrate-/Jerk-Max).

Third, I was unable to change any axis settings using Chilipeppr - although motor settings took effect. However, I was able to set these by manually typing the commands so this seems likely to be a Chilipeppr issue. Downloading from a configuration file also works fine further indicating fault-free operation of G2.

[stg]

Erratic motion problems seem related to arcs. The following code gives erratic motion on edge, but works just fine on master:

(Drill cycle, 2mm hole, 1mm tool, 2.4mm depth)
G0 Z0
G91
G1 Y0.5
G2 R0.5 Y-0.5 X+0.5 Z-0.2
G2 R0.5 Y-0.5 X-0.5 Z-0.2
G2 R0.5 Y+0.5 X-0.5 Z-0.2
G2 R0.5 Y+0.5 X+0.5 Z-0.2
G2 R0.5 Y-0.5 X+0.5 Z-0.2
G2 R0.5 Y-0.5 X-0.5 Z-0.2
G2 R0.5 Y+0.5 X-0.5 Z-0.2
G2 R0.5 Y+0.5 X+0.5 Z-0.2
G2 R0.5 Y-0.5 X+0.5 Z-0.2
G2 R0.5 Y-0.5 X-0.5 Z-0.2
G2 R0.5 Y+0.5 X-0.5 Z-0.2
G2 R0.5 Y+0.5 X+0.5 Z-0.2
G0 Y-0.5 Z2.4
G90
G0 Z2
(End drill cycle)

Trying to do 180° arcs (which was what I originally was using when getting erratic results) fails on master as well, but this 90° version works with master.

[aldenhart]

Thanks for the heads up. There are some updates to arcs that have not made it into the g2 code base just yet. Please stay tuned and we should get this done shortly. In the mean time most CAD packages will generate output without using the arcs.

[stg]

That is lovely news!
Thanks, I will try some things first (like IJ instead of R), but if I can't get it working, I'll rewrite it to G1's instead of arcs.

May I ask if the serial port issues I'm having are unheard of or known, perhaps even to be expected? It seems if I am careful, take my time and try not to use anything beyond the basics - the ports stay alive alot longer but I am yet to find any specific (series of) action(s) that repeatably triggers it. I stay away from !feedhold and %clear, as they seem to frequently break communication here.

[aldenhart]

We have not see the kinds of things you are experiencing with the serial ports. Have you tried Coolterm as a terminal emulator? Also, are you using a hub÷. We have seen some issues cuased by hubs misbehaving.

[stg]

Ok, let's consider it a local issue and I will troubleshoot on my end. I have not tried Coolterm, but will certainly do that. Tera term has been working nicely for me as well. I am using a hub, one I have not used before so it may very well be the culprit.

[ryansturmer]

FYI there's some more information on the arc issue here:

#44

[stg]

Thanks Ryan, I've read through that post and it is likely related - however I don't just get aborted arcs - I get all sorts of crazy moves. Yesterday my program went completely off course during an arc, feeding about 20cm off to the side before returning and continuing the next arc (at the correct position).

I am now pretty convinced things are not executed out of order, as I thought before - only I had some G0 Z0 moves after my G2 arc block that seemed to be executed in the middle of it. However, it seems that rapid positive Z axis shifts are one of the most common stray moves done during arcs. My program has 12 helix drills and all of them executed with Z moves at random points - changing behaviour between runs, but one of them consistently doing the mentioned 20cm-rapid-bit-breaking-XY-move-of-doom.

Since I am too eager and don't realize when to stop, I broke just about every single endmill I have yesterday so at least I don't have to worry about this for a week or so ;)

The USB serial issue seems to be triggered by feedhold and the pattern I had missed was that feedhold is used when jogging using the keyboard, but not using on-screen buttons in chilipeppr. I had thought they were the same, and the crashes therefore seemed random. I tried removing my hub, connecting straight to the computer - no change.

[stg]

I believe the USB issue is a combination of issue #41 combined with Windows sometimes strange handling of USB serial ports. I've seen this before with both FTDI and my own µC based USB projects when feeding to much data to a device that is (currently) not consuming said data. Even if the device begins consuming input again, the port is dysfunctional until cycling the driver either by software or by physically disconnecting/reconnecting.

[aldenhart]

Check out the latest edge branch - build 081.06 and above. There have been some changes to the arc code to bring it in sync with the v8 repo, and a timing bug was discovered on "stacks of arcs arriving one after the other"

[stg]

I saw you had done some commits and have been dying to get to my workshop ever since to try it out :)
Will be trying this out today.

[stg]

Great work, 81.07 runs beautifully!

Feed-hold still causes problems here, but it doesn't matter as I need not use it - but if I do I typically have to cycle the USB connection to get things going again.

Something I noticed with arcs in 81.07 which I am not sure if it's by design or not, follows.

This works nicely to produce a 1.5x2.4 helix:
G91
G2 I0 J-0.75 Z-0.8
G2 I0 J-0.75 Z-0.8
G2 I0 J-0.75 Z-0.8

If I'm not mistaken, ommitting X and Y should imply start-point and end-point are the same. However, doing the following (which I thought was equivalent) does not produce arcs (no XY movement):

G91
G2 I0 J-0.75 X0 Y0 Z-0.8
G2 I0 J-0.75 X0 Y0 Z-0.8
G2 I0 J-0.75 X0 Y0 Z-0.8

This is not really a problem, just wanted to inform you in case it is not the intended behavior.

[aldenhart]

Looks like I need to test not only for omitted endpoint coordinates, but also identical ones.

Can you explain what's happening with feedholds?

[stg]

First of all I am using Chilipeppr and hence only a single channel and I do understand the shortcomings of this and why an additional port is a good idea but this is not the issue. However, I find it difficult to describe exactly what it is that is happening, because a lot of the time it will work, but sometimes I end up in a state where I simply cannot get TinyG to accept commands until I cycle the connection. Manually trying to send commands to clear the queue and resume has no effect. Right now for example, I can't seem to replicate it, but it did happen with 81.07 just a short while back. You should probably not look into this until I can come up with a series of steps to reliably reproduce it. I will screencap my next few sessions and hope it happens again.

While testing now I also noticed that issuing a feed hold while a long single motion is performed does stop the motion, but only briefly. Right after decelerating to a full stop it is accelerated again and continues to run until the end of the move. Upon completion feed-hold takes full effect.

I also forgot to ask about/report an odd behavior when issuing multiple fast feeds with short duration on an empty queue - identical to double-clicking move by buttons in Chilipeppr with a suitable length, say 10mm while TinyG is idle. Replicated easily when machine is still - issuing two G0 X10 (G91 mode) immediately after each other. This will accelerate, feed, decelerate for the first move, but then jump straight back to full feed speed at the start of the second command (acceleration is skipped), followed by correct feed, deceleration. This causes loss of tracking every time one accidentally hits the move buttons too quickly. Can be worked around in host software, but seems a bit dodgy. I believe I have read about this elsewhere, but cannot seem to find it.

[aldenhart]

An update on your arc question - The failure on the second set of G2 arcs is expected and in spec. We follow LinuxCNC's definition of the Gcode spec. An arc with no endpoints specified is a full circle. And arc with the same endpoint specified is acceptable, but is interpreted as a zero length move.

[stg]

Thank you for the answer! There are just too many flavours of g-code in this world... I think it is good you are adhering as strictly as possible to a well defined standard (even though it bit me in this case).