Quite simply, the closer to the edge, the more accurate calibration will be. For every mm distance from the origin/center, any errors in calibration become more pronounced.
My intent was that Precision Calibration would only be run ~once, after a couple rounds of Edge Calibration (which is further from the edge). Tis way the long, destructive, time-consuming approach is saved for the last couple mm of accuracy.
Understood that’s the compromise I’m making. I’m only playing in the center area at the moment as I get other parts of the system dialed in. I’ll be running that calibration a few times and will reduce that number as I do.
I just tried using my machine on 234 and the z-axis has gone a bit crazy on me too. I also have an inverted z-axis.
Should I wait for a new build that handles negative z-axis or am I good with 234 to see what I am dealing with?
NB: I’m on like day 4 of actually using my maslow and have not done anything with the code at this point. Please take anything I say with a grain of salt and I defer to the developers on everything.
Interesting. I’m pretty sure that there is just a setting that is getting broken on the Z that does that. On mine I:
I couldn’t work out what was stuck the first time around, like I said, my general feeling is that some computation leaves the settings in a bad state and they need to be re-entered (why that wouldn’t work from the settings widget before I loaded webcontrol is a separate issue and could be user error so please try that first).
My settings are above. I just ran a bunch of cuts with it and while I have other issues they weren’t software related, Z has done over 100 plunge / retract operations without issue so 234 is viable once you work out why it is misbehaving.
@zaneclaes 234 looks good.
A couple things:
Thanks for all you efforts on this!
Looks like there may be a bug in the mm vs inches code. I had an Easel project that I left as mm when I exported. Makerverse was in Inches. When I went to move my Z-axis, it went crazy because I hadn’t paid attention to the increment value (right of the move buttons) and it somehow had set itself to 1000 INCHES. I panicked a bit until I could get control and kill the move since it was jamming my z-axis at the limit pretty hard. Obviously 1000 inches seems like a ridiculous number. It was when I opened the dropdown and saw 1219 inches (my machine limits in mm) that I realized it must be a conversion issue.
Okay, sounds like I will be testing with the Mega and an inverted Z axis tomorrow 
Would you mind sharing the settings you’re using for Z-axis distance per rot. and steps per rot.? @ltfiend already shared his; I’m guessing the Z problems have to do with these numbers, so I’ll test them specifically with my Mega tomorrow.
This part is so strange to me. The only thing that comes to mind is… have you paid attention to your WPos for the z-axis? Maybe it somehow got set to something other than the MPos. The two should be equal:
edit I realized that in the Calibration UI, I actually ensure that the WPosX == MPosX and WPosY == MPosY. This check ensures that I am moving the sled where I want to move it, in absolute units. But I make no such guarantee before moving the Z-axis in calibration. Perhaps this is the cause of the bug, given that the Z-axis bug doesn’t happen whilst cutting (after the wpos has presumably been updated to prep for the cut).
Well that’s good to hear, at least! I’d like to figure out what’s causing all the confusion, though, so I can hopefully prevent it for others. Like I said, I’ll wire up my old Mega tomorrow. I actually want to see if I can export from the Due into the Mega successfully. And I’ll test everything I can think of w.r.t. the Z-axis.
Thanks for the reminder on these. I should be clear — I know the app isn’t perfect yet, I’m mostly just trying to create a final list of things to have fixed for the public release. (1) and (2) are definitely on it
Ah, right. You need to put the scripts within the /home/pi/makerverse directory. You could also put them in a (new) sub-directory, like /home/pi/makerverse/events. Then, from within Makerverse UI, you reference them as /home/node/makerverse/events. Basically, the Pi “mounts” the makerverse directory (/home/pi/makerverse) into the Docker image at the path /home/node/makerverse, giving the Docker image access to the Pi’s makerverse directory.
Note, I’m lumping together “events” and “add-ons/widgets” in my To-Do list. I want to make it so you can just install useful things from within Makerverse, rather than needing to know all this shell voodoo 
Ack, yeah. I need to go revisit “unit-switching,” now that you mention it. The app never did a great job with it, and there’s probably some other edge cases I’m missing. I think the problem comes down to the fact that most Grbl devices reset to mm when they are reset or reconnected. However, the Maslow Mega firmware does not; it remains in whatever units until you tell it to change. I think this is screwing with Makerverse at times, so I’ll go dig in to that.
@Orob regarding Sleep… AFAIK, the Mega doesn’t support $SLP. Looking at the firmware, it has a pause() function, but AFAICT that is just the ! feedhold implementation. So just to be sure, the Sleep feature is for the Due only, right?
I was trying to test out your import bug. I noticed that the quotation marks in your export, above, had been changed from standard quotation marks: " into fancy quotation marks: “ and ”. Notice how the fancy quotation marks have two versions (open & close) that look slightly different. Some text editors make this conversion automatically, which is very annoying because it is not recognizable as JSON anymore.
Anyways, the good news is I can just fix it in the import process by subbing out the string. And just in case that ever doesn’t work, I also added error detection to the import process for the next version (see bottom). Not the most user friendly messages, but at least it’s better than mysteriously not doing anything.
exactly. The mega shuts off and the motors don’t hum when the system is active, whereas the due motors hum while it is on and the sleep stops the hum until a reset and unlock enables control again.
Okay, got it. Right now, I don’t have a way to set different UI features for the Mega vs. Due. That said, I can make the Sleep button be available, but have it show an “unsupported” message on the Mega for now when it is pressed.
Once I am able to start working on the Machine Profiles I’ve talked about, then the button will be hidable for Mega users who use the new “setup workspace from a well-known machine profile” flow.
don’t stress it. I can type it if it bothers me that much… I did get the link fixed so my status light works!
And I just wrote up an explanation on the topic for the docs 
Ah, good call. Being a unix person I should have checked for some character issue before assuming it was the numbers. I used google docs in this case as my notepad for swapping back and forth, I’ll use something else in the future.
I haven’t gotten back to the machine yet today but will try and do some more testing tomorrow.
Eh, it was easy enough to regex out the special quotes at the import level. I’m sure if you, a Unix guy, managed to fall victim to this then several others would have been vastly more confused.
I’m about to upload a build in the next ~1 hour that I hope has fixes for everything we’ve discussed.
Okay, new build (235) is on the way (30 minutes).
There was also an update to the bin/launch script. @Orob pointed out to me that the old versions were not being cleaned up, causing him to run out of disk space. The new version automatically removes old Makerverse versions before starting.
I just did the PID change for the 100 rpm z axis motor and this test z axis page would have been very nice. Great additions! Thanks for the sleep button! I read your doc for the events. I think it covers it, but for the rest of us perhaps a little more detail:
However, while inside the Makerverse application, the path to the shared folder is
/home/node/makerverse
I would append this to it:
for example: to run a bash script named green.sh to toggle an LED using the raspberry pi gpio, the system command would be ~/makerverse/events/green.sh and the green.sh file would be placed in the user/makerverse/events folder. The script green.sh may consist of:
#!/bin/bash
echo ‘w 26 1’ > /dev/pigpio
where the command writes a 1 to pin 26 using pigpio to toggle a digital output pin to turn on an LED. A multicolored status light may be used with 3 pins and the file might look like:
#!/bin/bashecho ‘w 26 1’ > /dev/pigpio
echo ‘w 19 0’ > /dev/pigpio
echo ‘w 13 0’ > /dev/pigpiowhere green is io pin 26, red is 19, and blue is 13. Multiple events could then be assigned to 9 different colors of the multicolor LED using 3 output pins and a ground from the raspberry pi.
well, maybe that is too verbose. Is there an event for when the gcode is finished running?
Let me put that part in a different section. The code you’ve pasted only applies to Raspberry Pis, and it’s really more about “how do I write a script?” and not about “how to install.” So I think the “main” part of the docs needs a section about “writing events / commands.”
I’ve only just started looking at the event code, but I believe gcode:stop is more or less what you want. There’s not an explicit “complete” event, AFAICT, but that’s something I do plan to add soon. I noticed Marlin sends percent-done feedback, for example, and has a hard time noticing when the program is done executing. So building a good “completed” detection (with a corresponding event) seems like a good idea to prevent confusion between normal “stoppage” and “successful completion.”
