The version 1.1.1b did update and the connection issue was resolved. The .makerverse seems a little short after recreation, compared to the example. Wish you a perfect day/night and see you on my weekend.
that is in a few hours…
1 Like
Yay!! Glad to hear it, and thanks for sticking in there and being patient.
1 Like
well, 2 steps forward, one back.
So I got Makerverse up and running and was able to move the sled.
In trying to calibrate, something got messed up. First, I couldn’t get the sled to move in the calibration screen
Then they moved backwards.
I wiped the settings hoping to start over. Need a break.
I’ll check the forums for calibration guidance and start over tomorrow.
1 Like
AFAIK, there’s only two possible reasons motors would move backwards. (1) they are wired into the wrong ports (2) the $3 setting is wrong (it inverts direction, and would have been cleared by your wipe). I’m very curious to hear what happened here.
When you try again, please confirm (via shuttling manually) that all motors work correctly before starting calibration, just to be 100% sure. If you end up verifying that it works okay before Calibration, but Calibration somehow breaks it, please send me a screenshot of all your Settings (in the Maslow panel) after calibration.
Okay, in attempts to debug, I created a .hex file myself. This way, I know you’re running the exact same firmware I am.
I think this is the correct version: cnc_ctrl_v1.ino.hex (169.6 KB)
But if that doesn’t work, this is the one “with bootloader” cnc_ctrl_v1.ino.with_bootloader.hex (185.9 KB)
If it still doesn’t work, please send me everything you see during startup. For example, when I installed that firmware, the first thing I saw in the serial output was the PCB version:
OK, I gave up on trying to use avrdude to flash the Arduino and reverted to Webcontrol to do it. Webcontrol says its running your custom firmware. After I stopped Webcontrol and ran SerialMonitor (still on my Webcontrol image), this is the output that started the stream…
PCB v1.2 Detected
FAKE_SERVO off
Grbl v1.00
ready
ok
[Forward Calculating Position]
position loaded at:
-0.00
-0.00
<Idle,MPos:-0.00,-0.00,4.73,WPos:0.000,0.000,0.000>
[PE:0.00,0.00,127,2090.14,2085.13]
<Idle,MPos:-0.00,-0.00,4.73,WPos:0.000,0.000,0.000>
[PE:0.00,0.00,127,2090.14,2085.13]
<Idle,MPos:-0.00,-0.00,4.73,WPos:0.000,0.000,0.000>
[PE:0.00,0.00,127,2090.14,2085.13]
I then shutdown the RPI, swapped SD cards to move back to the Makerverse image.
After stopping the Makerverse service, I again started Arduino IDE and Serial Monitor. Again, this is the output I saw at the start of the output…
nJM@⸮O⸮O⸮⸮⸮J<⸮4⸮⸮⸮⸮⸮nJM@⸮4⸮
M⸮b⸮9@M@C(M⸮ ⸮⸮iA7⸮⸮⸮ ⸮⸮7⸮,M⸮M-⸮I⸮p⸮'⸮
⸮@a⸮4AM⸮MPCB v1.2 Detected
FAKE_SERVO off
Grbl v1.00
ready
ok
[Forward Calculating Position]
position loaded at:
-0.00
-0.00
<Idle,MPos:-0.00,-0.00,4.73,WPos:0.000,0.000,0.000>
[PE:0.00,0.00,127,2090.14,2085.13]
<Idle,MPos:-0.00,-0.00,4.73,WPos:0.000,0.000,0.000>
[PE:0.00,0.00,127,2090.14,2085.13]
<Idle,MPos:-0.00,-0.00,4.73,WPos:0.000,0.000,0.000>
[PE:0.00,0.00,127,2090.14,2085.13]
Notice the garbled line to start the output…
I started Makerverse again, waited for it to boot, then tried to create a workspace. Same result.
By the way, I used the non-boot loader version.
Very interesting. I’ve seen this happen with USB ports before, but never consistently. It’s always been a “whoops, just try again” sort of thing.
In any case, I just pushed an update that causes Makerverse to see Grbl v1.00 as an acceptable Maslow Classic firmware, I think. I say “I think” because I can’t quite test your situation.
After restarting, you should see #183 in the “About” section (this is a build number).
Okay, I went back to the drawing board. Restart again and should have build #187.
I added a bunch more additional ways to detect the Mega, and tested it on my board. I really think/hope this one will fix it…
Stuck here also.
Plugged in my WEbControl PI to get the Ardino flashed.
Back to Makerverse. checked the work area size, motor offset and width between motors.
went to calibration tab, clicked ‘move’ motors make noise, sled lurches and stops.
I tried a second time. GOt it to move to top right, got those measurements. (they seem way off though, top measurement 387 mm, side 663. Moved to center, tried to get top center and just lurches again w/ message about sudden halt and lost position.Jogging also just causes the sled to lurch
Going back Web Control for today. Hope to get some things cut. Maybe start on an improved frame w/ longer chains
Good news to end the week!
3 Likes
This sounds like something on the Arduino level… maybe the “sled not keeping up.” When you press the “move” command, it just sends it directly to the Arduino. So if you’re having troubles moving in Makerverse, I’d also expect you to have troubles moving in WebControl. Let me know how it goes – I’m curious what’s going on here.
the sled is 14.65x14.65" and the router bit is NOT in the center of the plate. it is exactly 1" above the center from top to bottom. From left to right it is centered. .
1 Like
New, unrelated issue to report…
Now that I am past the Create Workspace issue I am able to load the workspace in the local browser using URL “makerverse:8000”.
However, I have found that the same webpage can NOT be accessed from my Mac using the same URL. (and the RPI is reachable since I have VNC open to it from the same machine.) “allowRemoteAccess” is true in .makerverse file. I have also found that even on the local RPI browser, Makerverse can’t be accessed using “localhost:8000”, “127.0.0.1:8000” or “192.168.1.130:8000” (the assigned IP address). Only “makerverse:8000” seems to work. In all other cases, the “Loading” spinner stays forever.
Can you access it via the RPi IP address (http://192.168.1.130:8000) from the Mac? I am able to access mine at both the IP address and http://makerverse.local:8000, but the latter is only possible if your home router supports DNS multicasting.
That’s odd. As you correctly identified, the allowRemoteAccess bit is the thing which should make this work. The pre-built Raspberry pi image is headless (no desktop), so I haven’t tried loading it from the RPi itself. You might try doing a force-refresh (cmd+shift+R) to ensure everything is reloaded on that page, not cached. I’ll keep thinking about this one and work on getting a pi with a desktop up and running…
Attempted access using http://192.168.1.130:8000 fails on both the Mac and RPI. I do believe DNS multicasting is working properly because I can reach the Webcontrol deployment on the same RPI using http://webcontrol:5000.
This seems like an issue with the webserver on the RPI since I am getting an initial page load to show “Loading” with the rotating circle. I’m not sure if there are connection logs for the webserver that may show something…
Bob
Hmm, yeah, that seems accurate given the symptoms. It really does sound like the Docker container is not listening on all interfaces. I think we need to run the container in Host Networking mode.
I just updated the bin/launch script again if you want to give it a try:
https://raw.githubusercontent.com/makermadecnc/makerverse/master/bin/launch
Just to humor me. try the IP address with out the ‘http://’
It should not matter.