Your Arduino did not respond with the settings when it was asked for them. It’s in a bad state and nothing should be working properly. Close and re-open the connection.
FWIW, I plan to add an “export settings.”
I don’t know why some people have these problems with the Arduino not always connecting properly. I would suspect bad USB cables and such. I know that’s a problem with some of the long cables that ship with the Maslow.
I just finished calibration with it and it is reported as within 1.8 mm. it is working just fine. I took a screenshot of the calibration, but didn’t save it before taking another and I want the numbers from it and they are not there.
I’m confused – you didn’t apply the calibration results when you were done?
EDIT: ---- I didn’t write them down. normally I will keep a record in a google sheet and missed it thinking I could get to them in the settings box and it didn’t work.----
I did apply them. They looked really good. but I cannot go back and look at the specifics. in the chain dialog window, you hide them unless I reset them and the settings tab isn’t showing anything so if I want them I need to plug into my pc and save the serial dump when it turns on.
I restarted makerverse and now the settings dock is working. sorry to make a stink over a minor issue.
Why not? Just re-connect the device and look at the settings.
Again, that should not have been necessary. The problem was when the USB connection re-opened (which happens at the end of applying calibration), the device did not respond. All you needed to do was close and re open the connection.
I closed and reopend the connection several times. the console was working. I queried the device with $I, but the list of information didn’t show up. A very odd situation. After restarting makerverse, it works.
If it ever happens again, please grab logs before restarting so I can know what happened 
I’m surprised because if you actually close the connection to the Arduino, it should totally reset everything. It’s hard to imagine how restarting would work but re-opening the connection wouldn’t.
A new build will be up in about ~30 minutes.
It has the toolbar enhancements from above.
It also has a first stab at the new “measure chains” flow.
I’m going to be away from my computer for the next 36h, so hopefully it runs smoothly 
You have been a mad man with the updates and addressing all these issues and making vast improvements. Thanks for all your hard work! I am going to cut today with my system and see how it goes. I’ll get the latest update and report back if there are issues.
Great! FYI I did find a bug with some gCode rendering at the wrong spot, so this update should fix that bug you had (“cut in the wrong spot”).
I put the system to sleep and after pressing reset, the unlock key was still disabled, so I had to disconnect and reconnect.
I cut something and used the work space offset. I positioned the sled where I wanted the temporary “home” to be and set the workspace x and y zero. When it cut it actually cut beyond the x limit of the machine… not a huge deal because I had stock overhanging and I guided it with my hand, but it was not expected and should have stayed within bounds. I measured with a tape from the sled based on the cut dimensions before starting, but what the picture showed on the screen based on the sled movements and the actual cut location did not match. The display location on the screen is to scale and does not match up with the location. There appears to be about 150-200 mm offset. I’ll get back with more precise details.
Could you provide the exact gCode file? Often IME this has to do with the origin used when the file was created. I thought this was fully accounted for now, but it’s possible your exporter is different than mine.
MnLogo_3-8_8th_3.5_550__0001.gcode (103.7 KB)
file attached
@Orob were you running the cut on a Mega? I just noticed that the visualizer had a hard-coded feature which made it think that Grbl setting $13 means “reports in inches.” In other words, if you have $13 as any value greater than zero, it thinks that the Maslow is sending inches (not mm) back to the visualizer. Since $13 represents something different on the mega, it is going to pretty much always be true, and cause a bug. Of course, the difference between the inches and mm is large, so this may or may not be related.
I’ll verify the starting and ending measurements for scale, but I thought it was pretty close to the intended size. I work in mm, so if it was in inches, it would have been 25x larger than intended.
I think the bug would manifest more as a scaling of the wpos in the visualizer. So it wouldn’t scale the cut itself, but a 150-200mm offset might have been caused by dividing the wpos (origin of the cut) by 25.4 when rendering the gcode in the visualizer.
Build #217 just uploaded and handles metric/imperial on the Mega better. I’m going to be cutting all day with my M2, so if there are any bugs that apply to both I should hopefully catch them. Maybe I can calibrate my Mega on my new frame in a day or two, before pushing the build out to a wider audience.
Over the weekend I successfully installed the software on a Pi4 (w/ mega) and with some work, I was able to get the system running. I noticed a glitch that I think others have flagged but under different circumstances.
To facilitate z axis zeroing I ran the G code because the widget is not operational. My gcode set the units to inches but the units did not change on the front end. Meaning my machine was set to inches but was displaying mm. I then moved the z axis 5 mm but it attempted to move 5 inches instead. So if anyone is running a gcode that is in inches be sure to toggle units if there is need to return to mm or vice versa. Until this is fixed be sure to keep track of the machines units.
Yeah, thanks for bringing this up. I think the problem is specific to the Mega. I did fix some bugs related to these units (described briefly above) this morning. Please do keep an eye on the units, and let me know if Build #218 still exhibits these problems.
