We already have touch plates for Z axis, and it already triggers an action.
why not use that same concept for finding the edge of the plywood?
put a 1/4" straight rod (no flutes) into the chuck and have the bit well below the surface, but outside the edge of the plywood. and have it work it’s way around the outside, jogging vertically to touch the plywood.
to create the electrical circuit, put aluminum foil tape along the edge of the plywood.
then the maslow could bounce around the outside, touching the edge, backing off, and moving a few inches further down the edge to find the edge again.
supporting the sled as it rides teh edge is a problem, but not insurmountable.
I then tried opening “192.168.1.130:8000”, “127.0.0.1:8000”, “localhost:8000” and “makerverse:8000” locally in the RPI Chromium browser (in that order). Only “makerverse:8000” loaded.
rather than moving the sled and measuring from the edge of the workpiece to the sled or between the holes to calibrate, you would tell the system how big the sheet is and the system would “measure it”.
@mrgnstrn an interesting idea for sure. It violates the size constraints of the system because right now you tell it how big the system is and it will not go outside those bounds, but it would have to in order to run around the outside of the board, yet that idea is interesting to me because it eliminates the user measurement error. Have the system measure the 4 corners of the plywood and then everything else should fit within, so then it could find its home position.
@Bob_Craig just to confirm, with each of these URLs, you are able to open the “landing page,” but the loading indicator never disappears? Including from the other machines? Or do some of those addresses not work at all?
All variations DO reach the landing page and get the Loading message. All variations on all machines fail at “Loading” EXCEPT “makerverse:8000” on the local RPI (meaning even localhost:8000 on the RPI gets stuck at “Loading”). I’ve tried from the RPI, my Mac using Chrome, and an Amazon Fire tablet running Silk.
Just for the fun of “DO NOT TRY THIS AT HOME!” and “DO NOT MESS WITH CONFIG FILES WHEN DRUNK!” i did both and after being locked out of makerverse for the hundreds time, i did what i should not have done and edited the .makerverse (DO NOT DO THIS! IT COULD BE BAD!)
The outcome is surprisingly pleasant as i’m connected automaticity
Confirmed Ubuntu and mac with firefox:
Drunken feature request. Ignore.
Can we make a circle in the diameter of the sled around the little dot? My eyes are not that good to find the small thing
This sounds a lot like a “cross origin” error. This kind of error happens when one site tries to load another site internally. For example, it might happen if you open localhost:8000 and that page tries to load makerverse:8000 (because it thinks that is the correct URL for the server, when it should also be using localhost). Very strange that others have not experienced it, and moreover this security feature should be disabled.
Anyways, it would be very helpful if you could open up the “Developer Tools” on one of the failing URLs. In Chrome, press View → Developer → Javascript Console. You should see something like this. I’m curious if there are big red errors:
You can also flip over to the Network tab. If my hypothesis is correct, you’ll see red items there where it failed to load something from the server. Hover over a request, and you can see the URL. Here you can see that all my network requests were successful (white), and that they’re being loaded from localhost:8000 (same as my web browser).
Also one last thing – if you make changes to your settings (e.g., add a workspace, turn on prereleases), do those settings persist after you restart the app? Do you see them appear in the ~/.makerverse file? I just want to be 100% sure nothing strange is happening there.
In general, sudo systemctl [COMMAND] [SERVICE]. In this case, service will always be makerverse. Commands are enable & start, restart, status, stop & disable. This is true of all Linux services, aka, programs that run automatically. Enable=start automatically, FYI, as opposed to just start.
This was happening with an old bin/launch script, about 24+ hours ago, if you haven’t updated that script (it doesn’t auto-update).
If it still doesn’t work, take a look at the ~/.makerverse file after creating an event. It should have changed to include the event. If you can indeed see the event created in the file, try checking it again after restarting Makerverse. Does it get deleted or something after restart?
I was using the older script. I updated both the firmware and the makerverse scripts with the git pull function, which worked great. and I saw this message and found it curious:
20200905 is tomorrow. Apparently I need to upgrade again?
