Strange; I am not seeing this when I use FAKE_SERVO on my Mega.
Things to try/ask:
I’ll give those a try this evening.
I just noticed something else after doing my test run. It appears that after finishing the work, the Job buttons stayed disabled. I’m guessing the only way I can re-enable them is to reset the board connection.
What do you expect the behavior to be? Feels like a possible bug to me.
I’ve noticed some erratic behavior around the end-of-job, as well. Orob and I were talking above about how Marlin (3d printers) never even realizes it has finished. From your screenshot, though, it looks like the “GCode” widget knows that all the lines have been processed.
Looks like I need to update the GCode widget. It should:
… anything else? @Orob
I knew I’d remember something after I posted…
OK, I’m not sure what is different this attempt but the behavior has changed for the better. I did zero out the WPos on both attempts. Obviously, though, on my first attempt something went wrong because it cut relative to MPos, not WPos. On my second attempt the UI is updating correctly and I believe is cutting relative to WPos. I’ll confirm when it is done cutting in 1 hour.
Thanks for the suggestions (and the logo) 
I’m moving slowly this week because I have been focused on my girlfriend’s birthday. I whipped up this craft table for the sewing machine I bought her, and today we’re headed camping. I’ll be back to full steam working on these bugs & features later in the weekend.
Interesting, someone else reported something very similar on just the first cut. I’ll look in to this; LMK how the rest goes!
Ok. First full sheet cut test this am on an Opendesk Desk. Running build #239. Process was:
A couple of things to report:
During 1st cut, I paused the program to move the dust collection hose. Then resumed the program. The machine moved from its location in the bottom left corner straight up to the mid-line. The z axis did not raise. Then the program resumed normal cutting.
Several times during the cut, the machine took a little siesta. I was able to pause and then restart. It seems to have been related to tab cuts?? Here is a screenshot of the gcode.
Cuts in the lower left corner of the sheet walked around and did not maintain consistent pathways.
Question (I wonder if this is an easel issue) - I was surprised at the tool paths during several cuts - on a 18 x 6 rectangle, it would start in the upper right corner, cut the top 18 inches right to left then traverse back to the upper right corner without cutting. The machine would lower the bit to the next depth and repeat the cut. This would repeat until final cut depth. Then the machine did the same with the bottom half of the rectangle, only this time starting in the lower left corner and cutting left to right. It seems that it more than doubled the amount of movement necessary to make the cuts?
Thanks,
Scott
The scrambled position reports look strange.
is a bit like switching from a microscope to a magnifying glass. What program was used?
dxt to g-code is preferred for me.
I could take a look at the g-code if you upload it. I use camotics and bcnc for g-code forensics.
Do you have a 10 or 12 ft top beam? The left chain seems to steep to vertical to be still able to pull left.
More weight on the sled can help a little, but more motor distance is more secure.
Here is the gcode that easel rendered. Thanks in advance.
Slim Desk with svg import (3).nc (340.4 KB)
There is some crazy stuff going on in this g-code.
Apart from the many zig-zag in the air across the sheet that will more then double your cutting time for no reason, there seems to be some parts merged into one or so. Was the dxf on different layers?
Also lots of Z-5 moves to safety before the next pass. Lots of time wasted here also.
There is something wrong with this file.
Ok. Thanks for looking at it. I’ll start over. The original dxf from Opendesh was in multiple layers - based on cut position and depth of cut.
you can use ABviewer to flatten the DXF to one layer. it has a free trial.
Thanks for the work zaneclaes!
We are a couple of students who just have built the Classic Maslow. It’s a pretty standard top beam frame. We also have a Metal Maslow sled, but with the classic Z-axis. Metal maslow creator was very nice and sent us the plans, to have the sled water jet cut.
Ran through the calibration for the first time on Windows build #239. There were some problems, mainly UI realated. We got an accuracy of 4.2mm after one edge calibration.
Right now I’m setting up a Rpi3 to use as controller. The image is the older one before tablet UI was added. It doesn’t seem to update beyond #241. There might also be a problem with docker prune. I got it to work, but I think I had to use sudo to get some space back on the SD card. The original 8 GB card got full and wouldn’t update due to disk full. Right now running a 16GB card.
Can you please elaborate? Hard to fix without more details 
There’s your problem. The Raspberry Pi official docs say you need at least 16 Gb: Raspberry Pi Documentation - Getting started
Also, the docker prune was only added to the very recent images. If you installed an older image, it may not have this feature (unless you manually updated your bin/launch script). When you run the bin/launch script it will tell you exactly how much space it reclaimed. If you don’t see such a message, you’re on an old image.
I’ll add this to the Makerverse docs.
Yes, of course I’ll elaborate on the UI problems. But I’ll run calibration again and come up with some good comments. The one I can remember right now is when putting in the offset from home after clicking go to home. For a new user it’s not trivial what is positive X and what is positive Y.
I’m running a 16 GB card right now, and the launcher says no updates.
Hmm? I’m not sure what you’re describing, here. There is no “go home” button. There is a “go to origin” button (0/0), and you should not need to do any sorts of modifications or edits for it to work.
How do you mean? In the cartesian coordinate system (aka, an X/Y/Z grid), positive X is always to the right, and positive Y is always up. The numbers are also shown on the screen of Makerverse, so you can see the actual locations relative to where the bit/sled is:
The prune process we are discussing is something different from the update process. If you’re running a recent version of the launch script, you will see this:
Removing old versions (pruning docker)...
Deleted Containers:
...
...
deleted: sha256:03e98db8a5c2b09ac7bd09a7679ddac2cdd5161189007561f24195c1a0b533ab
Total reclaimed space: 1.045GB
This will happen any time you run the bin/launch script (and thus whenever Makerverse starts), regardless as to if there is an available update.
Running #241 it appears there is a bug in the Pause/Resume logic, as mentioned above (I think).
As I was cutting a part, I noticed a piece had dislodged (apparently the tabs weren’t thick enough). I paused the machine with the “pause” button - the router turned off immediately. I cleared the dislodged piece and then pressed “Play” again. The router started its planned movement again - HOWEVER, the router never turned on again. The router turned on automatically at the start of the cut. I believe Webcontrol’s default behavior was to leave the router running (no M03 or M04 sent when pausing). However, I think it would be better if the Pause works as it does now (turns off the router) and automatically restarted the router when resuming.
The other bug is when Homing (as mentioned above). After Stopping the cut (since the router wasn’t on), the router did not retract to the travel position before starting to move to Home (after I pressed X/Y Home in the Jog controls). The sled tried to drag the bit across the workpiece (fortunately I was watching for it and lifted the sled). I believe the software should automatically retract the Z axis to a safe travel distance before any Jog commands are processed.
I’ll check for an update to the software just in case this may have been fixed in the past few days.
Great points, Bob. I’m just getting back to work today after the festivities, so no updates yet. But I’ll work on both of these things first thing tomorrow morning.
Re: the second issue, this one of those cases where the Maslow is “unique.” Most machines have a “homing sequence,” but the Maslow really only has a “go to 0/0” command. If you look at the UI, the button is not called “Home” but it is actually called “Go to origin 0/0” – but only when using a Maslow (not other machines, which do have homing). So when Makerverse tells it to “home,” what the Maslow sees is “go to 0/0.” I guess what I really need to do is build a pseudo-homing-sequence. But Grbl doesn’t actually have a concept of a “safe retract distance.” So I will need to add that to the M2 firmware as a new setting.