Can someone tell me why the CP simulator shows the toolhead jumping over the

Can someone tell me why the CP simulator shows the toolhead jumping over the fillets on the edges I made with fusion? During the run, it appears the machine mills the rounded ends, but the simulator shows the tool head skipping the filletted edges.

Also, I still seem to be having problems with the router frequently plunging below the G54 zero point. It happens more frequently the more often I reset the zero. I have tried resetting the controller, closing and reopening the browser, clearing and flushing the browser (I think I did it right) and turning my computer off and restarting it. Turning off the comp and back on is usually has the better result, though not always. It is also necessary for me to turn off the machine if G54 zero will not reset.

Simulator never had g2 arcs working even though they render. Somebody would have to go edit the code to have the animation follow the sub lines of arcs

Oh, okay. That’s what you were talking about in the jacut video.

I use no arcs for post process because I found jobs that did NOT mill correctly with arc (light blue in chilipeppr). I have not narrowed down the file but I have one that draws a reverse circle for one arc then goes on without problem. I was going to try it on a Mach3 machine to make sure I can nail down a case for not using them but it’s trivial to just change the post processor to not use arcs but I don’t know how you change it in Fusion.

Second point, me too. I just jammed a bit into a piece this morning. It’s flaky from what I can see. It is also the inch and mm stuff that gets confused. Resetting the z zero will work fine then suddenly it does nothing on the z DRO but reloading chilipper seems to fix it. But I have to remember that even though I tell it it is inches it come up with mm on the DRO. I hit the button for inch and double check by jogging. It’s a pain because any missed step and I can ruin a piece. There is something very flaky about it so pinning it down is not easy. When the DRO does not reset to zero the only thing that works for me is reloading and starting over. That along with chilipeppr memory limits leave it just shy of being a great tool instead of a tool that is not as reliable nor as capable as my Mach3 setup. I still use it for small engravings but that z problem is not fun when it ruins hours of work.

Maybe that’s what was causing my machine to misbehave

Anyone know why serial port would stop showing up? I blew a PSU and had to change. I finally got controller and PSU to respond but serial port won’t open

The FTDI device is not showing up on my computer

oddly enough one enhancement that i 90% coded but couldn’t find time to finish was to reduce arcs to smallish movements (and linear moves too) in order to smooth the ‘lumpiness’ of the autolevelling. that had the positive repercussion of making the arc traversals much more visually useful in the sim (effectively lots of small linear jumps).

I’ve got some very long flights coming up in ten days so will try to take a look at the code again then. if someone else wants to have a shufti it is in my github within the autolevelling widget (search for interpolate).

@Steve_Anken - what usb chip does your controller use? there are known issues with serial comms on some versions of the 32u.

@George_Allen - possibly a burned out uart? is it definitely FTDI or possibly another chip? if a 32u then you can query it via spi or (I think) debugWire

@Justin_Adie The interesting thing on your converting G2/G3 arcs to G1 moves is that the data is already in the 3D viewer. When a Gcode file is imported into ChiliPeppr, the 3D viewer creates one array element for each line of Gcode. It generates the XYZ start and end position per line and then renders. When it’s a G2/G3 arc it adds a sub-object to the array element. That sub-array has all of the smaller lines that were rendered by the 3D viewer. I always thought what you could do is simply add a menu item to the Gcode widget that says “Convert all G2/G3 arcs to G1” and then presto, you’d get a new Gcode file reloaded into the workspace that’s, of course, much larger, but has all G1 lines based on what you saw in the 3D viewer.

What makes it compelling to do this finally is that it took a good year to debug all the arc generation code for all the edge cases, but I think ChiliPeppr has nailed all arc scenarios in the 3D viewer because I don’t see bug reports on that anymore.

+John Lauer: that is interesting, and potentially a better solution.

but in reality it took me only a few minutes to break an arc into smaller arcs by maths and it would have been far longer to learn the intricacies of three.js to address the internal API.

Note that I don’t convert arcs to linear movements, but to smaller arcs. I’m not attempting to do anything complex here: just take the existing i/j/k data and reduce the interior angle by a known ratio given by the chord length. It’s not perfect but it is intended only to be interpolative. So whatever CP fixes through the edge case analysis you’ve done, all I was doing was granularising it, not undoing it.

Ahhh. That is interesting. I wonder if that solution could introduce errors because the hard part I found was when looking at ijk values you have to decide direction of the arc and they’re were some rounding errors in JavaScript when you’d get beyond 6 decimals that would make an arc go clockwise instead of counter clockwise. I think there were about 5 other esoteric bugs as well that I found no good docs on that had to be figured out by trial and error.

One thing I did was just convert arcs using 32 straight line segments. That can be overkill in small arcs so my approach was not very intelligent.

Im so depressed. I just blew out my second TinyG board after burning out my Meanwell 24V 350 PSU.

There only time I’ve blown a tinyg is reversing the polarity in the input of 24v.

ha! possibly. I had some sniffer code that determined direction by reference to whether it was a G2 or G3 arc and then either added or subtracted the ratio.

the code was very rough. I had only a 90 minute train journey and spent some of it analysing the mm/in issue …

probably it would be better to extract the parsing code from grbl. - then the edge cases will inevitably not be worsened by the interpolator.

Apparently I’m pretty good at it